RetroSearch Browse

Thu Oct 30 11:20:37 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-October/039829.html

On Thursday 30 October 2003 04:43 pm, Guido van Rossum wrote:
> > >     a = [3,2,1]
> > >     print a.sorted()
> > >     print list.sorted(a)
> >
> > Actually, yes, it IS compelling indeed.  Funny -- I was originally just
> > brainstorming / musing out loud, never thought about this as a "real
> > thing".  But now that it's matured a bit, I do feel sure [...]
>
> If you feel about it that way, I recommend that you let it mature a
> bit more.
>
> If you really like this so much, please realize that you can do this
> for *any* instance method.  The identity
>
>    C.foo(C()) == C().foo()
>
> holds for all "regular" methods.  (Since 2.2 it also holds for

Yes, having a be an instance of list in the above doesn't show 'sorted'
as being any different than a perfectly regular instance method -- it
WAS in this sense a bad example (I thought I'd mentioned that later
on in the very same post?).  The identify I want is rather like:

    C.foo(x) == C(x).foo()

for an x that's not necessarily an instance of C, just something that
has a natural way to become one.  When C is list, any iterable x,
for example.  In other words, being able to call C.foo(x) _without_
the typechecking constraint that x is an instance of C, as one would
have for a normal C.foo unbound-method.

> extension types.)  If we were to do this, we'd be back at square two,
> which we rejected: list instances having both a sort() and a sorted()
> method (square one being no sorted() method at all :-).

Yes, the names are an issue again -- but having e.g. x=L1.sorted(L2)
completely ignore the value of L1 feels a bit strange to me too (as
does x=D1.fromkeys(L3) now that I've started thinking about it --
I've never seen any Python user, newbie or otherwise, have actual
problems with this, but somebody on c.l.py claimed that's just because
"nobody" knows about fromkeys -- so, I dunno...).

Darn -- it WOULD be better in some cases if one could ONLY call
a method on the class, NOT on an instance when the call would in
any case ignore the instance.  Calling dict.fromkeys(L3) is wonderful,
the problem is that you can also call it on a dict instance, and THAT
gets confusing.  Similarly, calling list.sorted(iterable) is wonderful,
but calling it on a list instance that gets ignored, L1.sorted(iterable),
could perhaps be confusing.

Yeah, the C++(staticmethod)/Smalltalk(clasmethod) idea of "call
it on the instance" sounds cool in the abstract, but when it comes
down to cases I'm not so sure any more -- what might be use
cases where it's preferable, rather than confusing, to be able to
call aninst.somestaticmethod(x,y) "just as if" it was a normal
method?  Would it be such an imposition to "have to know" that
a method is static and call type(aninst).somestaticmethod(x,y)
instead, say...?

Oh well, I guess it's too late to change the semantics of the
existing descriptors, even if one agrees with my newfound doubts.
But the funniest thing is that I suspect the _new_ descriptor type
would be the _least_ confusing of them, because calling such a
method on class or instance would have semantics much closer
to ordinary methods, just slightly less typeconstrained.  Oh well!

Alex

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/039829.html below:

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