[Python-Dev] join() et al.

M.-A. Lemburg mal@lemburg.com
Thu, 18 May 2000 11:43:57 +0200


Tim Peters wrote:
> 
> [M.-A. Lemburg]
> > ...
> > Uhm, aren't we discussing a generic sequence join API here ?
> 
> It depends on whether your "we" includes me <wink>.
> 
> > Well, in that case I'd still be interested in hearing about
> > your thoughts so that I can intergrate such a beast in mxTools.
> > The acceptance level neede for doing that is much lower than
> > for the core builtins ;-)
> 
> Heh heh.  Python already has a generic sequence join API, called "reduce".
> What else do you want beyond that?  There's nothing else I want, and I don't
> even want reduce <0.9 wink>.  You can mine any modern Lisp, or any ancient
> APL, for more of this ilk.  NumPy has some use for stuff like this, but
> effective schemes require dealing with multiple dimensions intelligently,
> and then you're in the proper domain of matrices rather than sequences.

The idea behind a generic join() API was that it could be
used to make algorithms dealing with sequences polymorph --
but you're right: this goal is probably too far fetched.

> > >  That said,
> > >
> > >     space.join((eggs, bacon, toast))
> > >
> > > should <wink> produce
> > >
> > >     str(egg) + space + str(bacon) + space + str(toast)
> > >
> > > although how Unicode should fit into all this was never clear to me.
> 
> > But that would mask errors and,
> 
> As I said elsewhere in the msg, I have never seen this "error" do anything
> except irritate a user whose intent was the utterly obvious one (i.e.,
> convert the object to a string, than catenate it).
> 
> > even worse, "work around" coercion, which is not a good idea, IMHO.
> > Note that the need to coerce to Unicode was the reason why the
> > implicit str() in " ".join() was removed from Barry's original string
> > methods implementation.
> 
> I'm hoping that in P3K we have only one string type, and then the ambiguity
> goes away.  In the meantime, it's a good reason to drop Unicode support
> <snicker>.

I'm hoping for that too... it should be Unicode everywhere if you'd
ask me.

In the meantime we can test drive this goal using the -U command
line option: it turns "" into u"" without any source code change.
The fun part about this is that running python in -U mode
reveals quite a few places where the standard lib doesn't handle
Unicode properly, so there's a lot of work ahead...

> > space.join(map(str,seq)) is much clearer in this respect: it
> > forces the user to think about what the join should do with non-
> > string types.
> 
> They're producing a string; they want join to turn the pieces into strings;
> it's a no-brainer unless join is hypergeneralized into terminal obscurity
> (like, indeed, Python's "reduce").

Hmm, the Unicode implementation does these implicit
conversions during coercion and you've all seen the success...
are you sure you want more of this ? 

We could have "".join() apply str() for all objects *except* Unicode.
1 + "2" == "12" would also be an option, or maybe 1 + "2" == 3 ? ;-)

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/