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

[Todd]

On Aug 10, 2014 9:51 PM, "Andrew Barnert" <abarnert at yahoo.com.dmarc.invalid>
wrote:
>
> 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.

Couldn't this also be handled with a keyword argument to join?  For example
"joiner.join(iofs, convert=True)".

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

This seems like something an abstract base class could take care of.

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

Isn't this an implementation detail that could be fixed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140810/1823a8ab/attachment-0001.html>