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

[Andrew Barnert]

On Sunday, August 10, 2014 11:26 AM, Terry Reedy <tjreedy at udel.edu> wrote:

 
> 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)".


If concat instead meant "joiner.join(map(type(joiner), iofs))", that might be more useful than just a synonym. I've seen many novices try to figure out how to join up their list of ints.

Also, it could conceivably be faster for user string-like classes, especially mutable ones (because then, as long as they had slice replacement, everything else would happen in C, whereas if they have to write a custom join, it will be looping in Python).

Also, being a new function, it might be reasonable for concat to handle iterators differently from sequences (exponential expansion rather than preallocating). I've seen a couple people asking why ''.join(genexpr) uses twice as much memory as they expected (although far fewer than the joining-up-ints questions).

Of course any (or all) of those also might well be a bad idea in its own right. But a new function gives us a chance to think through how it should work—and then, if it turns out it should work exactly like join, the answer may be "just a synonym, reject it", but if not, it might be reasonable to add it and gradually phase out join.