[Python-ideas] The non-obvious nature of str.join (was Re: sum(...) limitation)

Terry Reedy tjreedy at udel.edu
Sun Aug 10 20:25:08 CEST 2014


On 8/10/2014 8:33 AM, Nick Coghlan wrote:
> (switching from python-dev to python-ideas)
>
> FWIW, I don't consider str.join *or* sum with an empty string as the
> starting point to be particularly intuitive ways of joining iterables of
> strings.

I think sum(iofs, '') is obvious and I do not understand the 
determination to not allow it and implement it as ''.join(iofs). 
Perhaps that is because I think '+' is the *right* choice for string 
concatenation.  Addition of tallies (base 1 numbers) is concatenation. 
For tallies, or strings, r and s, len(r+s) == len(r) + len(s).  (That 
this is not true of sets is a reason to not use '+ for set union, which 
Python doesn't.)

(I also think sum(it_of_lists, somelist), which is allowed, should be 
implemented as somelist.extend(it_of_lists), but that is another issue.)

> str.join was invented before we had keyword-only arguments as a common
> construct, and before print became an ordinary function that accepted a
> "sep" keyword-only argument.

The reason sep in print has to be keyword-only is because print takes an 
indefinite of main arguments rather than an iterable of items to print. 
This is appropriate because we generally print a few items that are not 
already in a collection, because collections of strings can be .joined, 
and because collections can have, and builtin collections do have, 
methods to join the string representations of their members. Print, str 
and .__str__ methods, and str.join works together wonderfully.

The start paramenter of sum does not need to be keyword only because sum 
takes one iterable of items to sum. This is appropriate because a few 
items to sum, not in a collection, can be handled by '+', and sum is 
needed for large collections of items already in a collection.

> I'd be interested in seeing a concrete proposal for a "concat" builtin
> that accepted a "sep" keyword only argument. Even if such a PEP ends up
> being rejected, it would hopefully help cut short the *next* potentially
> interminable thread on the topic by gathering the arguments for and
> against in a more readily accessible place.

For the against list: New builtins should add something more than a pure 
synonym;  "concat(iofs, sep=joiner)" is harder (6 more letters), not 
easier, to write than "joiner.join(iofs)".

-- 
Terry Jan Reedy



More information about the Python-ideas mailing list