gah! I hate the new string syntax

[Alex Martelli]

"Amit Patel" <amitp at Xenon.Stanford.EDU> wrote in message
news:97soak$qh9$1 at nntp.Stanford.EDU...
    [snip]
> When I see split(a,b), I think, "Oh, this isn't an inherent part of a
> string-- *I* could write it, even though I didn't write the string
> object."
>
> When I see b.split(a), I think, "This is a basic part of a string, and
> I *cannot* write it."

Reasonable, but the latest assertion is a bit too strong -- tone down
to "cannot write it without typeswitching or other potential inefficiencies
since it doesn't do a general dispatch on b".

E.g., take the .read, .readline and .readlines method of file objects.

Clearly, given one of them, you might write the others as functions,
not as efficiently maybe, and maybe with some typeswitching.  It's
more efficient to let the file object supply them all, just like it's more
efficient to let the string object supply join and split methods (so
one doesn't have to typeswitch between singlebyte and Unicode, &c),
but it's an issue of practical effectiveness, not one of theoretical
purity (practicality trumps purity...).


> If I have a split-like function I'd like to write (perhaps
> re.split, or some custom split function), then what I'll see is:
>
>           function style              method style
>
>           string.split(a,b)           b.split(a)
>           re.split(a,b)               re.split(a,b)
>           mysplit(a,b)                mysplit(a,b)
>
> Note that with the function style, they're consistent -- MY function
> is on equal footing with string.split.  But with the new method style,
> the split method on strings is elevated to a privileged position that
> I cannot do for mysplit.  So now I have inconsistent syntax.

But not if the .split is a method on your objects -- re.split being a
good example, as it will be simpler (no need to cache, typeswitch,
etc) to use a bound method than a function.


Alex