polymorphjsm &c (was Re: I come to praise .join, not to bury it...)

Huaiyu Zhu hzhu at mars.localdomain
Fri Mar 9 09:36:37 CET 2001


On Wed, 7 Mar 2001 11:11:17 +0100, Alex Martelli <aleaxit at yahoo.com> wrote:
>
>but neither do you get what you want, because a.split(b) works
>irregularly...:
>
>    -- if a is a re object, or if it's module-object os.path,
>        then string b is split using splitter-object a
>    -- if a is a string object (including a Unicode string),
>        then string a is split using splitter-object b (which
>        must also be a string)
[...]
>
>It's no doubt too late to remedy the discrepancy between
>the semantics of a.split(b) depending on a's type (string
>versus re) and the resulting irregularity (which we no
>doubt will have to live with anyway) is unpleasant, to say
>the least.

Maybe not too late?

sep.splits(thing)     => list 
sep.joins(list)       => thing

list.joinswith(sep)   => thing
thing.splitswith(sep) => list

This would allow sep to be either string, re or os.path, etc. The words
joinswith and splitswith are comparable to startswith, endswith.

In any case, we have to live with two orders of split whichever way the
original design goes.  How else would one reconcile the following?

re.compile.split         # sep.split(string)
file.read.splitline      # string.split(sep)

But honestly, after seeing all these arguments and switching opinion twice I
come to believe only multimethod would be the true solution.  Wait for Py3k?

Just-realize-I-was-promoting-TMTOWTDI-ly yr's

Huaiyu



More information about the Python-list mailing list