I come to praise .join, not to bury it...

[Alex Martelli]

"Russell E. Owen" <owen at astrono.junkwashington.emu> wrote in message
news:9b4nen$ka2$1 at nntp6.u.washington.edu...
> In article <rodB6.6847$4N4.1487790 at newsc.telia.net>,
>  "Fredrik Lundh" <fredrik at pythonware.com> wrote:
>
> >Jürgen A. Erhard wrote:
> >> One of the best: Smalltalk does has `join' as a method of
> >> *collections*, not strings!  One *might* think that the designers of
> >> Smalltalk were... well, not the most stupid people on the planet.
> >
> >if you can find Python's collection base class, we're happy
> >to add a join method to it.
>
> I am curious about that. What *would* be involved in creating such a
> base class or collection class hierarchy? I can imagine several uses for

It would take little to write a collection class, but making
_types_ (as opposed to _classes_) "inherit" from a class would
require major surgery to Python.  As things stand, types just do
not "inherit".  Lists, strings, Unicode strings, tuples,
dictionaries and arrays (in standard module array) are all
types.

> it (in addition to join), including:
> - subclassing to make new kinds of collections; collection could do most
> of the work

You can do that now, as your 'new kinds' would presumably
be classes, not types.

> - type checking (is this an instance of the collection base class?)

This is the part that could not be made to work today.  PEP 246
would remedy this -- rather than asking if something 'IS' an
instance [insert here a copy of ALL of Korzybksi's diatribes
against 'IS' -- he was right!-)], you'd ask for "conformant
adaptation" of the object to the collection protocol, and either
the object (if written with knowledge of the protocol, e.g. by
inheriting it if it so chooses) or the protocol (if written with
knowledge of the object's type, e.g. for pre-existing types such
as lists, tuples, &c) could respond appropriately -- bliss!

> - the % operator could work on any kind of collection; I occasionally
> try to use a list instead of a tuple

That would break existing code:

>>> print "ba%sbo"%range(2)
ba[0, 1]bo

this would presumably have to fail if it became equivalent to:

>>> print "ba%sbo"%(0,1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: not all arguments converted

Besides, % works quite differently when the RHS is a dictionary
rather than a tuple.  I suspect we won't live to see THIS part
remedied to your satisfaction.


Alex