There is reference-counting sorcery in unicodeobject.c also:
There is reference-counting sorcery in unicodeobject.c also:
Well, sure, PyUnicode_Append lives there⌠But this is basically just the implementation of unicode_concatenate, right?
I donât see that it is actually used anywhere in unicodeobject.c for string operations or APIs (but it does look like itâs used as a shortcut in the compiler and a handful of stdlib modules).
I am still very puzzled on why sum excludes a string from being used as a start. That is the ultimate of not doing one thing thatâs understood by all users. It wouldnât have broken at all if behind the curtains if a string sum would have been implemented differently. The only problem I can see that when an object is inherited from str had defined a __add__ method. But that could have been detected by checking if the __add__ of start equals the __add__ method of str. Like (pseudo code)
def sum(iterable, start=0):
if isinstance(start, str) and start.__add__ == str.__add__:
return start + "".join(iterable)
return orgsum(iterable, start) # orgsum is like current sum without a TypeError for str's.
I think itâs time to rethink this, as the developers (@guido and @rhettinger ?) seem to have overseen this possibility.
I am still very puzzled on why sum excludes a string from being used as a start. That is the ultimate of not doing one thing thatâs understood by all users. It wouldnât have broken at all if behind the curtains if a string sum would have been implemented differently.
The point I was getting at is that thereâs already a correct way to do this that is efficient without lying to the user. If there wasnât another simple way, then this would be a very different discussion.
For what itâs worth, I too think the TypeError is a bit heavy-handed, especially considering how nice the interpreter is regarding string addition in general. But I do understand that the motivation was probably educational rather than technical, and in general I donât think itâs a bad thing.
This is an unusual case where the Right Way and the Obvious Way are not necessarily the same thing. So new users make the mistake once, learn the correct way, maybe Google why itâs better, and move on to greater things.
The Zen of Python says:
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless youâre Dutch.
Well that obvious way is to use sum to concatenate a list of strings. That might not be obvious at first, but (like @guido) I am Dutch.
I would like to propose a PEP to change the behaviour of sum for strings. What would be the best way to proceed? Anyone who is familiar with this process, please advise.
There should be one-- and preferably only one --obvious way to do it.
I feel that this is easily the most misunderstood line of the Zen. Nobody is arguing that sum isnât obvious, or that str.join is. Itâs been pointed out several times, though, that the right way (which the Zen says nothing about), in this case, is different. Thatâs probably why the author of sum felt justified in raising an error here.
I would like to propose a PEP to change the behaviour of sum for strings. What would be the best way to proceed? Anyone who is familiar with this process, please advise.
I am familiar with the process. The first steps are gathering feedback and finding at least one core developer who agrees with you.
Adding to this, you can also consider starting a new thread on python-ideas to reach a wider audience. Just make sure that you try to address all of the main points that have been previously brought up against it (including those in this topic).