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

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