At 10:16 AM 1/13/05 +0000, Armin Rigo wrote:
>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",
Possible solution: have it break when it's used in a non-subtype of
'type'. That is to say, when it's not used in a metaclass.
>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).
Hm. I look at this the opposite way: sometimes it's nice to provide a
default version of a callable that's supposed to be stuck on the object
later, just like it's nice to have a default initial value for a variable
supplied by the type. I don't think that doing away with this feature for
non-special methods is a step forwards.
>In all cases, I'm +1 on seeing built-in method objects (PyMethodDescr_Type)
>become data descriptors ("classy descriptors?" :-).
Heh. :)
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