Home Original page

String.join revisited (URGENT for 1.6)

François Pinard pinard at iro.umontreal.ca
Sat Jun 3 21:32:23 EDT 2000 
aahz at netcom.com (Aahz Maruch) writes:

> So far, nobody has pointed out *ANY* disadvantages of retaining the
> current string.join() mechanism, with one exception: it destroys the
> "orthogonality" of moving all string functions to string methods.

I never really saw `string.join()' as a string method.  My guess why it
has been put there?  It was easy to explain `join' next to `split', given
they kind of complement each other, and have elegant argument similitude.

`string.split' was well decided, because it is clearly a method on strings
(on the first argument, _not_ the second).

`string.join' has been named and decided after its result, _not_ after
its arguments (and surely never after its second argument).  This was bad,
slightly confused, but bearable then.  Trying to propagate this old error
into a string class absolutely underlines it was a bad choice, and raises
horror in all souls having a bit of purity left! :-)

`string.join' is not, and has never been a string method.  That `join'
has been put into `string' for documentation convenience, nothing more.
We never, never decide how to sort methods by their result.  We always do
it by their most important argument.  The fact that the joining string
has been put second, and even optional, is another proof that it is not
the important argument (neither for `string.split', by the way).

Let's merely recognise the error, and correct it, instead of forcing ugly
intellectual stunts on everybody to justify it.  It dirties Python.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard
More information about the Python-list mailing list