[Python-ideas] The non-obvious nature of str.join (was Re: sum(...) limitation)
Stephen Hansen
me+python at ixokai.io
Mon Aug 11 19:45:34 CEST 2014
On Mon, Aug 11, 2014 at 10:10 AM, Haoyi Li <haoyi.sg at gmail.com> wrote:
> > In fact, it makes very logical sense once you explain it and makes
> people think of things more Pythonically after. I say from experience, not
> in theory.
>
> Could you elaborate about "making people think more pythonically after"
> bit? I can see how explaining the API makes people understand the API, but
> I'm curious how it makes people behave differently after.
>
Well, its an opinion of course, so it may be as useful as the thought that
the sky is high. It doesn't make people behave differently, but it does
lead them to writing idiomatic code. There's naive Python code, which
ideally should be clear and easy still, and then there's idiomatic Python
code which has a beauty in its expressiveness while also being (relatively)
efficient.
But, if the opposite of "string.split(sep)" were
"list_of_strings.join(sep)" then that would mean that List would have to
know about how to combine strings. That's not very Pythonic. Also, Strings
are immutable, that means:
str1 = str1 + str2
logically leads one to assume that it is constructing an entirely new
string, copying the contents of str1 and str2 into it, and discarding the
original str1. In fact, it did that for a long time. You can't change
strings, after all. That is an fundamental tenet, and when people learn
that they will get a new tool and think closer to idiomatic Python. Now,
CPython has an optimization for this case which is the only reason the idea
of sum(list_of_strings) is not largely fundamentally broken, but that's not
a promise and not a feature of the language.
IMHO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140811/4b37a01b/attachment.html>
More information about the Python-ideas
mailing list