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

[Alex Martelli]

"Carel Fellinger" <cfelling at iae.nl> wrote in message
news:983u1l$6mk$1 at animus.fel.iae.nl...
    [snip]
> >>> class MixedSplitter:
> ...     def __init__(self, splitter1, splitter2):
> ...         self.splitter1, self.splitter2 = splitter1, splitter2
> ...     def split(self, sequence):
> ...         s = self.splitter1(sequence)
> ...         return s[:-1] + self.splitter(s[-1])

self.splitter will give an AttributeError here (you mean .splitter2).
But you won't get here unless self.splitter1 is callable, and who
ever said it was?  Guess you mean self.splitter1.split(sequence) on
the first line, and similarly self.splitter2.split on the second.

With these changes, you get no errors any more out of your code:

> >>> ms = MixedSplitter(', ', ' and ')
> >>> ms.split('1, 2, 3 and 4')
> some nasty errormessage snipped

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)

I.e., the semantics are backwards in the two cases, alas.


> But the real evil is that no code out there will allow us to easily
> use the polimorphic nature of this splitter.

Actually, code written to split by a regular-expression object
(which it takes as an argument and only uses for splitting)
will work fine, polymorphically, with your MixedSplitter (when
the latter is amended to call the split methods of its splitter
attribute objects!-) -- as long as MixedSplitter is correctly
primed with two splitter objects, and string objects are not
splitter-objects in Python's architecture; they have a .split
method, but it doesn't work at all like those of regular expression
objects and the os.path module object do -- it's backwards.


> The moral being that we shouldn't argue about the uglines joiner.join
> but of the lack of a tru polymorphic splitter.split!

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.


Alex