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

[Stephen Hansen]

On Mon, Aug 11, 2014 at 8:47 AM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

>
> On Mon, Aug 11, 2014 at 10:59 AM, Mark Lawrence <breamoreboy at yahoo.co.uk>
> wrote:
>
>> Could you try something which to my understanding is unprecedented in the
>> world of computing, as in point them to the docs?
>
>
> Sure - this is the universal remedy to any design mistake, but how many
> people would need to look at the docs to understand something like
> join(list, sep=',') or split(string, sep=',')?  And how many of those
> seeing x.join(y) and x.split(y) for the first time will guess which
> argument is data and which is separator?
>

Two new builtins now?

"x.split(y)" is ambiguous because its terrible code, not because of the
order. Names matter and exist to provide clarity. Don't name variables 'x'
and 'y'. If it were as simple as "x.split(sep)" or "x.split('\t')" then I
bet almost no one will need to consult the documentation to know which is
which; similarly with "sep.join(list_of_strings)". Now for someone wanting
to know how to join a list of strings and doesn't know how,
sep.join(strings) is not per se obviously discoverable, but it isn't that
bad and people will have to go to the docs anyways. They are likely to look
in the string section I think, and find it. They might look in the list
section, and may look in the bulitins section, but its still not that bad.

As for how many would need to go look it up with your proposed builtins,
anyone who wanted to set the separator, that's how many. And considering
"," is not even kind of a sensible default for either, that'd be a lot.

I remember this discussion very clearly when sum went in, and again during
the py3k period, and here the zombie rises again.

 Beautiful is better than ugly.
> Explicit is better than implicit.
> ..
> Readability counts.
> ..
> In the face of ambiguity, refuse the temptation to guess.
> There should be one-- and preferably only one --obvious way to do it.
> ..
>
> (The Zen of Python, by Tim Peters, AKA python -m this)
>

The Zen are nice words and good pieces of advice that are not a tool to
wield to win an debate, especially since most of them are fundamentally
subjective and require you to think in Python for their full meaning to
have an impact. They were also written after the fact by a long margin as a
joke, even if like most jokes they have a measure of truth in them.

Adding builtins defies 'Explicit is better then implicit', and though
",".join(stuff) is arguably less then beautiful, the axiom says *better*
not *best*, and the order of things to almost any function at all could be
called ambiguous until you look it up. Finally, at least ",".join(stuff)
directly (and explicitly!) refuses any temptation to guess.

Zen aside, I'm not sure if sum(list_of_strings) is that pancea of
readability and beauty and who-needs-documentation-now that its sort of
implied in this thread, that it doesn't work for strings is for reasons
already specified (CPython's immutable strings implies it could lead to
*BROKEN* behavior in a reasonable implementation, even if CPython currently
has a limited optimization). I ever so much don't believe we need "join"
and "split" builtins, I much rather think your arguments for forcing people
to use str.join make more sense, but I hope we don't see that either.

This isn't a situation that causes a huge amount of confusion. Teach the
students that sep.join(list_of_strings) make sense because who would know
how to combine strings, but a string itself? Of course list_of_strings
wouldn't know this. Watch the awareness blossom. Sometimes I think people
overstate how big a deal things are in teaching because we all care about
making Python teachable.

--S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140811/3400fce7/attachment.html>