I come to praise .join, not to bury it...
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...
| > 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
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