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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4