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

[Haoyi Li]

One reason I think this is confusing is that "list.join(sep)" is how
basically everyone else does it, including: Ruby, Javascript, Scala,
Guava-Java (normal java doesn't have anything). People who don't do it this
way include C# (static method), Boost-C++ (static method), PHP (static
method)

Nobody does it the Python way AFAICT.


On Mon, Aug 11, 2014 at 10:45 AM, Stephen Hansen <me+python at ixokai.io>
wrote:

> 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/39f299c4/attachment.html>