> > 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com