String.join revisited (URGENT for 1.6)

Greg Ewing greg at
Tue May 30 06:00:03 CEST 2000

Fredrik Lundh wrote:
> as people have pointed out a couple of hundred times in this thread,
> lists and tuples are *heterogeneous* containers. you can put *any*
> kind of Python object in them, not just strings.

So what? It's also been pointed out that it's quite feasible
to define a join that makes sense for more than just strings,
and that string joining can be efficiently accommodated as a 
special case.

Personally, I don't think that such a generalised join belongs
as a method of *either* argument.

I certainly agree that it doesn't feel right as a method of the
separator. But I don't think it should be a method of the sequence
either, for various reasons:

1. It's defined in a way that doesn't depend on any details of
   the sequence object. It can do its job quite satisfactorily
   from outside, using the standard sequence protocol.

2. It should be able to operate on any kind of sequence -- lists,
   tuples, user defined classes, etc. Given 1. above, and the lack
   of any common base type for sequences in Python, the easiest
   way to ensure this is to keep it separate.

I think that a suitably generalised join should be a builtin, 
like map and reduce.

> or don't -- I'm sure your time could be better spent on hunting down
> real problems in the 1.6 alphas...

Bugs can be fixed at any time. But if we don't speak up soon
before what we see as a serious aesthetic mistake becomes entrenched,
it will be too late. We fear that it is too late already.
Comments about the number of hundred times that our arguments
have been dismissed in another discussion group that we
haven't been participating in don't help to alleviate that 
impression... :-)


Greg Ewing, Computer Science Dept,
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at	   +--------------------------------------+

More information about the Python-list mailing list