An alternative approach to bound methods
Jeremy Hylton
jeremy at alum.mit.edu
Tue Feb 20 12:11:16 EST 2001
More information about the Python-list mailing list
Tue Feb 20 12:11:16 EST 2001
- Previous message (by thread): An alternative approach to bound methods
- Next message (by thread): An alternative approach to bound methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>>>>> "TC" == Tim Couper writes: TC> What we lose is the ability to access class attributes by TC> getting an attribute of an instance (in case they are not TC> functions, because you could not do it when they are functions TC> anyway). It's not a problem except compatibility. When scopes TC> nest, you can just refer to these names unqualified. You can TC> also refer to them qualified by the class name, which works as TC> now from any place where the class is accessible. TC> What do you think? I'm not sure I really followed this argument. Perhaps some code examples would help. The ability to access class attributes via self is pretty fundamental property of Python. I don't expect it will go away. Also note that nested scopes do not allow access to class attributes as unqualified names. When resolving free variables, class scopes are skipped. This decision was made because we wanted to enforce the rule that all access to class and instance data should be via self. TC> _________________ TC> FWIW I think that this seems an excellent suggestion; for one, I TC> would find it a real asset to have such a seemingly python-esque TC> way of having class functions/static methods available in this TC> manner. What is the procedure to bring this suggestion the the TC> powers-that-be? Write a PEP. http://python.sourceforge.net/peps/ Jeremy
- Previous message (by thread): An alternative approach to bound methods
- Next message (by thread): An alternative approach to bound methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list