[Python-Dev] join() et al.
Thu, 18 May 2000 00:34:05 -0400
> 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.
> > 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
> 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").
simple-tools-for-tedious-little-tasks-ly y'rs - tim