Comment on draft PEP for deprecating six builtins

[Jeff Shannon]

In article <bHDz8.34855$n4.7400665 at newsc.telia.net>, 
fredrik at pythonware.com says...
> John Roth wrote:
> > To me, .join() makes much more sense as a list or tuple method than
> > either. Semantically, .join() takes a sequence and transforms it into
> > a string, therefore it should be a method on the input type (the
> > sequence)
> 
> there is no sequence type in Python.  try again.
> 
> </F>

Not only that, but Python encourages developers to create objects 
that fulfill the sequence protocol.  Your proposal would force 
__join__() to be part of that protocol, along with __getitem__() 
et. al., thus making custom sequences significantly more awkward 
to write.  (Especially considering that the most sensible 
implementation of this join method would not vary significantly, 
thus creating heaps of boilerplate.)  Oh, and let's not forget 
that these __join__() methods must account for plain-string-
vs.-unicode issues, too.

Conversely, by declaring join() to be a method on strings, it 
becomes quite simple (indeed, free) for *any* sequence to be 
joined, regardless of whether that was expected by the original 
author.  And being sure to get the right plain-vs.-unicode option 
is trivial, too -- that's handled by Python's normal 
polymorphism, instead of requiring typechecking in join().  And 
if, god forbid, a third type of string-like object were 
introduced, then (providing that it implemented join() 
reasonably) all existing sequences would *already* be able to be 
joined into that third string-like type, too -- again, for free, 
instead of requiring modification (and *more* typechecking!) in 
*each* sequence-like class.

-- 

Jeff Shannon
Technician/Programmer
Credit International