getting special from type, not instance (was Re: [Python-Dev] copy confusion)

[Guido van Rossum]

> > The descriptor for __getattr__ and other special attributes could
> > claim to be a "data descriptor"
> 
> This has the nice effect that x[y] and x.__getitem__(y) would again be
> equivalent, which looks good.
> 
> On the other hand, I fear that if there is a standard "metamethod" decorator
> (named after Phillip's one), it will be misused.  Reading the documentation
> will probably leave most programmers with the feeling "it's something magical
> to put on methods with __ in their names", and it won't be long before someone
> notices that you can put this decorator everywhere in your classes (because it
> won't break most programs) and gain a tiny performance improvement.
> 
> I guess that a name-based hack in type_new() to turn all __*__() methods into
> data descriptors would be even more obscure?

To the contary, I just realized in this would in fact be the right
approach. In particular, any *descriptor* named __*__ would be
considered a "data descriptor". Non-descriptors with such names can
still be overridden in the instance __dict__ (I believe this is used
by Zope).

> Finally, I wonder if turning all methods whatsoever into data descriptors
> (ouch! don't hit!) would be justifiable by the feeling that it's often bad
> style and confusing to override a method in an instance (as opposed to
> defining a method in an instance when there is none on the class).
> (Supporting this claim: Psyco does this simplifying hypothesis for performance
> reasons and I didn't see yet a bug report for this.)

Alas, it's a documented feature that you can override a (regular)
method by placing an appropriate callable in the instance __dict__.

> In all cases, I'm +1 on seeing built-in method objects (PyMethodDescr_Type)
> become data descriptors ("classy descriptors?" :-).

Let's do override descriptors.

And please, someone fix copy.py in 2.3 and 2.4.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)