[Python-Dev] Re: Guido's Magic Code was: inline sort option

Alex Martelli aleaxit at yahoo.com
Thu Oct 30 04:24:09 EST 2003


On Thursday 30 October 2003 06:31 am, Guido van Rossum wrote:
> > Notwithstanding the "perverted" implementation, Alex's idea is
> > absolutely wonderful and addresses a core usability issue with
> > classmethods.
>
> I'm not so sure.  I think the main issue is that Python users aren't
> used to static methods; C++ and Java users should be familiar with
> them and I don't think they cause much trouble there.

"Yes, but".  The ability to call something on either the class OR the
instance IS a Python hallmark... with the constraint that when you
call it on the class you need to provide an instance as the first arg
(assuming the "something" is a normal instance method, which is
surely the most frequent case).  You could see universalmethods
as being special only in that they WEAKEN this constraint -- they
let the 1st arg be EITHER an instance OR something from which
a new instance can be naturally constructed.

Use cases:


in gmpy:

    if I had universal methods, current instancemethods
        mpf.sqrt
    and
        mpz.sqrt
    (multiprecision floatingpoint and integer/truncating square roots
     respectively) could also be called quite naturally as
        mpf.sqrt(33) and mpz.sqrt(33) respectively.  Right now you
     have to use, instead, mpf(33).sqrt() or mpz(33).sqrt(), which
     is QUITE a bit more costly because the instance whose sqrt
     you're taking gets built then immediately discarded (and building
     mpf -- and to a lesser extent mpz -- instances is a bit costly); OR
     you can call module functions gmpy.sqrt(33), truncating sqrt, or
     gmpy.fsqrt(33), nontruncating (returning a multiprecision float).

     Just one example -- gmpy's chock full of things like this, which
     universalmethod would let me organize a bit better.


in Numeric:

     lots of module-functions take an arbitrary iterable, build an array
     instance from it if needed, and operate on an array instance to
     return a result.  This sort-of-works basically because Numeric has
     "one main type" and thus the issue of "which type are we talking
     about" doesn't arise (gmpy has 3 types, although mpz takes the
     lion's share, making things much iffier).  But still, Numeric newbies
     (if they come from OO languages rather than Fortran) DO try
     calling e.g. x.transpose() for some array x rather than the correct
     Numeric.transpose(x) -- and in fact array.transpose, called on the
     class, would ALSO be a perfeclty natural approach.

     universalmethod would allow array instances to expose such useful
     functionality as instance methods AND also allow applying direct
     operations -- without costly construction of intermediate instances
     to be thrown away at once -- via "array.transpose" and the like.


It's not really about new revolutionary functionality: it's just a neater
way to "site" existing functionality.  This isn't surprising if you look at
universalmethod as just a relaxation of the normal constraint "when
you call someclass.somemethod(x, ... -- x must be an instance of
someclass" into "x must be an instance of someclass OR -- if the
somemethod supports it -- something from which such an instance
could be constructed in one obvious way".  Then, basically, the call
is semantically equivalent to someclass(x).somemethod(... BUT the
implementation has a chance to AVOID costly construction of an
instance for the sole purpose of calling somemethod on it and then
throwing away the intermediate instance at once.

No revolution, but, I think, a nice little addition to our armoury.


Alex




More information about the Python-Dev mailing list