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