[Python-Dev] join() et al.

2000年5月18日 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/