Movatterモバイル変換

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

• Previous message (by thread):I come to praise .join, not to bury it...
• Next message (by thread):I come to praise .join, not to bury it...
• Messages sorted by:[ date ][ thread ][ subject ][ author ]

"Russell E. Owen" <owen at astrono.junkwashington.emu> wrote in messagenews: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 forIt would take little to write a collection class, but making_types_ (as opposed to _classes_) "inherit" from a class wouldrequire major surgery to Python.  As things stand, types just donot "inherit".  Lists, strings, Unicode strings, tuples,dictionaries and arrays (in standard module array) are alltypes.> it (in addition to join), including:> - subclassing to make new kinds of collections; collection could do most> of the workYou can do that now, as your 'new kinds' would presumablybe 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 246would remedy this -- rather than asking if something 'IS' aninstance [insert here a copy of ALL of Korzybksi's diatribesagainst 'IS' -- he was right!-)], you'd ask for "conformantadaptation" of the object to the collection protocol, and eitherthe object (if written with knowledge of the protocol, e.g. byinheriting it if it so chooses) or the protocol (if written withknowledge of the object's type, e.g. for pre-existing types suchas 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 tupleThat would break existing code:>>> print "ba%sbo"%range(2)ba[0, 1]bothis 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 convertedBesides, % works quite differently when the RHS is a dictionaryrather than a tuple.  I suspect we won't live to see THIS partremedied to your satisfaction.Alex

• Previous message (by thread):I come to praise .join, not to bury it...
• Next message (by thread):I come to praise .join, not to bury it...
• Messages sorted by:[ date ][ thread ][ subject ][ author ]