[Python-3000] Abilities / Interfaces

[Steven Bethard]

On 11/22/06, Guido van Rossum <guido at python.org> wrote:
> Examples that keep recurring are things like the
> smtplib.SMTP.sendmail() method, whose second argument
> is either a string or a list of strings.
[snip]
> Rewriting this as a generic method
[snip]
> sounds like a total waste of time and code. Expecting that
> authors of alternative String implementations would care enough about
> this obscure and super-specialized method to add a binding for their
> type (smtplib.SMTP.sendmail[MyStringType] =
> smtplib.SMTP.sendmail[str]) would be naive.

I'm probably totally off base here, but I thought Phillip's suggestion
would be not for people to be registering their types for functions,
but to be registering their type's methods with the classes they're
supposed to be emulating.  So I would have expected something like:

    str.lower[MyStringType] = MyStringType.lower
    str.split[MyStringType] = MyStringType.split
    ...

And then they wouldn't register themselves for smtplib.SMTP.sendmail;
they'd just rely on that function asking for a ``str.lower &
str.split`` or whatever as its second argument.  (Does seem like there
needs to be some sort of shorthand though for "all the string
methods".)

> 2. Numbers are another example. They are very common arguments to
> functions and methods. Very few people write their own number
> implementations, because the built-in ones are so good. But there
> *are* people who do, for very specialized reasons (numpy has a whole
> slew of new number types). I don't think it makes sense to turn
> everything that takes a number as argument into a generic function.

Again, I may have misunderstood the proposal, but I didn't think you'd
be changing the functions that took numbers, I thought you'd be
registering the new number type's methods with the builtin methods
they were intended to emulate, e.g.::

    int.__add__[MyIntegerType] = MyIntegerType.__add__
    int.__mul__[MyIntegerType] = MyIntegerType.__mul__

(or however + and * are supposed to be registered).

> Now, due to duck typing, if you just *use* numbers, and the numpy
> folks have done their job, things will just work -- this is your
> argument about using generic operations. But as soon as any type
> testing happens (e.g. when writing an API that takes either a number
> of a string or a list of numbers), I'd much rather have a few "big"
> interfaces (Number, RealNumber, Integer)

Yeah, it certainly seems like in both this case and the string case,
there needs to be some shorthand for saying "implements all the basic
String/Number/whatever methods".


STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy