[Python-ideas] Why not ['a','b','c'].join(',') ?

[Christopher Barker]

I think is was a couple years ago that someone on this list suggested a
“commonly suggested and rejected ideas” PEP.

I don’t know that it should be a PEP, but it would be a good idea to have
such a document in an “official” place.

We could start with this one.

Interestingly (to me), Chris’s explanation is a good one, but I don’t think
historically accurate.

IIRC, the join method was added to strings  pretty early on, when most of
the other methods were added. Back in the day (1.5 anyway), strings were
pretty simple objects, and you did most string manipulation with functions
in the string module, e.g.

import string
a_string = string.upper(a_string)

The string module had a join() function -- lists did not have a join method.

Strings themselves had (I think) no methods -- the only "functionality"
they had was what other sequences had (slicing, "in", etc), and the %
formatting operator. Which makes antoher point -- strings ARE sequences, so
if sequences had a join() method, then strings should have a join() method,
too, but it would join the items ini the sequence -- i.e. characters -- not
really that useful ;-)

When the string object was introduced (expanded) to have a full set of
methods, it grew most of the functions in the string module, so naturally,
join() was one of them. (
https://docs.python.org/3/whatsnew/2.0.html#string-methods). NOTE that a
promary motivator for making stringoperations methods was that then unicode
and "Old style" strings could have the same interface.

As it turns out, str.join() works with any iterable, which is really nice,
but back in the day, Python was more about sequences than iterables [1],
and it still made sense that join really belonged with str, as it is
inherently a string operation -- sure, any python object can be
stringified, but not all objects actually produce a useful string
representation, so a "stringify_and_join" method on every sequence is
pretty out of place. And, as Chris points out, impossible for every
iterable.

[1] String methods were introduced in 2.0, and the iteration protocol was
introduced in 2.1: https://www.python.org/dev/peps/pep-0234/

-CHB








On Sun, Mar 24, 2019 at 9:02 AM Chris Angelico <rosuav at gmail.com> wrote:

> On Mon, Mar 25, 2019 at 12:28 AM Jonathan Fine <jfine2358 at gmail.com>
> wrote:
> >
> > Disclaimer: I've not recently read any discussions of this topic. And
> everything I say is my own opinion.
> >
> > SUMMARY
> > The syntax of Python's string join operator are a consequence of
> Python's core design decisions and coding principles, together with the
> semantics of join. I'll explain this in a series of posts.
> >
> > Why str.join? Wouldn't list.join be better?
> > ===============================
> > Python variables don't have types. Python objects do have types. When
> writing Python, don't test for the type of an object, unless you have to.
> Instead, test to see if the object has the methods you need.
> >
> > Eg help(dict.update)
> > update(...)
> >     D.update([E, ]**F) -> None.  Update D from dict/iterable E and F.
> >     If E is present and has a .keys() method, then does:  for k in E:
> D[k] = E[k]
> >     If E is present and lacks a .keys() method, then does:  for k, v in
> E: D[k] = v
> >     In either case, this is followed by: for k in F:  D[k] = F[k]
> >
> > Now for the semantics of string join. By Python principles
> >     From a str and an iterable
> >     The string join operator
> >      Produces a str
> >
> > You question amounts to this. Should the signature be
> >     (str, iterable) -> str    # Informal type signature of join.
> > or should it be
> >     (iterable, str) -> str
> >
> > At first glance, there's no way of choosing. But in Python we prefer
> >     aaa.join(bbb)
> > to
> >     from somewhere import join
> >     join(aaa, bbb)
> >
> > So the question now becomes: Choose between
> >     str.join(iterable)
> >     iterable.join(str)
> >
> > There is some sense in having list.join. But in Python, we can't join
> the elements of a list without getting an iterable from the list (unless
> there's something like very special short-cut-semantics built into Python).
> >
> > So in Python the choice is between
> >     str.join(iterable)
> >     iterable.join(str)
> >
> > Now str.join looks more attractive. But I said, without thinking ahead,
> that the syntax of Python's string join operator is a consequence of
> Python's core design decisions and coding principles, together with the
> semantics of join.
> >
> > I'm not quite there yet, there's a gap to fill.  I'll pause for a day or
> two now, just in case someone else wants to JOIN in the discussion, and
> perhaps fill the gap.
> >
>
> It's way WAY simpler than all this. "Iterable" isn't a type, it's a
> protocol; in fact, "iterable" just means "has an __iter__ method".
> Adding a method to iterables means adding that method to every single
> object that wants to be iterable, but adding a method to strings just
> means adding it to the str type.
>
> And, this is a topic for python-list, not python-ideas, unless someone
> is proposing a change.
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190324/62fd9056/attachment-0001.html>