String.join revisited (URGENT for 1.6)

[Manus Hand]

I really hate to jump in here, since so many people have already criticized
the length and content of this thread, but well, here I am.  And I have three
points to make.

First...
As one of those fools who grab the alpha version and recode everything
I've ever written to it, I have already gotten used to ''.join() [and I like it].
The view that someone posted here, that ','.join(list) can be viewed as
sending a "message" (each list member) to the string object ',' was all I
needed to get my head around the (admittedly initially strange) construction.

Second...
The fact that the string module will continue to exist (BTW, I really like
not having to regularly type "import string" when I start any code effort!)
is inherently a breach of the "proper" Pythonic view on TMTOWTDI.
It is my understanding that string.upper() will still exist, and I have not
seen this being argued as a reason not to support ''.upper() in 1.6.
''.join() seems to be the only case where TMTOWTDI is argued.
And if string.upper(y) is going to be equivalent to y.upper(), it only
makes sense to me from a consistency standpoint that string.join(x,y)
be equivalent to y.join(x).  [I gotta admit, I did like the ability to default
the separator and get a space, but this is a small trade-off for not having
to import string all the time.]

Third...
Before I learned that it was ''.join(list), I myself posted here wondering
why it was not [].join(string).  As I wrote above, I am now used to it
(and comfortable with it) being the way it is, but one thing about this
continuing debate has kind of always bothered me.  One argument
against it being [].join(string) is that this would mean implementing a method
for lists that only works on lists of a certain type (i.e., lists consisting entirely

of strings).  No one seems to question that, so I will (and I'm sure I'll
be corrected, which is fine).  But as the devil's advocate, tt just seems to me
that [].join() could be implemented such that each member of the list is str()'ed
or repr()'ed and then stuck together in the result string.  I imagine that one of
the fatal flaws in this, though, is how self-referential lists would be handled:
   >>> x = ['a']
   >>> x.append(x)
   >>> x.join()        # I would argue we get an exception?
If that is the only issue (which is being voiced as, "this would force
a method on lists to only work on CERTAIN lists") then I will understand
the major argument against [].join() at least a LITTLE more.

In short, I am (like anyone cares) in favor of standardizing on the ''.join() that
1.6a2 offers, and [purely for backwards compatibility, though I'm one of those
fools who recode everything, like I said] retaining the string module despite the
fact that it now means there will be two ways to do certain things.

In order to make THAT internally consistent in the language, we would want
(would we not? :-) to introduce a "list" module:
   >>> import list   # yeah, that would be a problem, given the builtin list()
   >>> x = [1]
   >>> list.sort(x)   # now an alternate way to write x.sort()
and a "dict" module:
   >>> import dict
   >>> x = { 1: 2 }
   >>> dict.keys(x)   # now an alternate way to write x.keys()
   [1]

I'm getting loopy.

Manus