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

D-Man dsh8290 at rit.edu
Wed Mar 7 19:41:36 CET 2001

On Sat, Mar 03, 2001 at 09:29:55PM +0100, Alex Martelli wrote:
| "Russell E. Owen" <owen at astrono.junkwashington.emu> wrote in message
| news:97p7iq$kk2$1 at nntp6.u.washington.edu...
|     [snip]
| > However, I do agree that join is not intuitive. I believe the problem
| > (at least for the way I look at it) is that join should be a list
| > method, not a string method. I.e.:
| >
| >   joined_string = ['a', 'b'].join(', ')
| >
| > makes a lot of sense to me. The current join string method does not.

This was my opinion as well.

| This seems to be a widespread opinion, and I've already tried
| to explain why my take on it differs, but that was a few months
| ago, and apparently the current crop of discussants hasn't read
| those discussions, so, let's give it one more spin.
| Python does not have multi-methods: it's a single-dispatch

Where can I learn about multi-methods and their

| So, since we want general polymorphism on the joiner
| object, but are quite content with polymorphism through
| the standard sequence interface on the sequence object,
| it is _just right_ that .join be a method on the joiner
| object (e.g., a string) and that it take the sequence of
| string to be joined as its argument.

Ok, so instead of calling "join" a "string method" how about using the
following Java-Python hybrid snippet to describe it :

interface Joiner :
    abstract Object join( Sequence s ) 

class String implements Joiner :
    String join( Sequence s ) :
        oh, cool.  I can mix and match the signatures sensibly without
        casting ;-)

This does make sense to me.  It looks logical and reasonable.  You
have convinced me Alex.  Your English (and writing) classes have paid
off ;-).  You must have been a writer before computers took over ;-).


PS.  BTW I haven't finished reading this thread yet

More information about the Python-list mailing list