At 10:18 PM 12/3/2007 +1000, Nick Coghlan wrote: >Phillip J. Eby wrote: > > Well, for what class-level frame hacking is typically used for, it > > would suffice to have a convenient way to refer to the local > > namespace, e.g. if you could do something like: > > > > implements(@, IExample) > > > > where @ was a shortcut for locals(). The most-used frame hacks (in > > zope.interface and most PEAK tools) just want to access the namespace > > of the current class definition, and maybe decorate the class in some way. > >Aren't the metaclass changes in PEP 3115 partially aimed at eliminating >the need for stack frame hackery to implement these kinds of things? >(e.g. the metaclass could stuff a closure into the class namespace under >the name 'implements' to avoid any need for frame hackery).
Doesn't help. You're assuming a *single* metaclass, which means you can't use things from more than one library in the same class. It defeats any possibility of modularity. I want method decorators and class-body decorators to be able to work, and to be able to use ones from different libraries in the same class, without needing to do manual metaclass mixing. If Python automagically generated mixed metaclasses (as described in the book that Python's metaclass rules largely come from), it would be a lot less of a problem. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
