Are decorators really that different from metaclasses...
jepler at unpythonic.net
Mon Aug 30 04:42:46 CEST 2004
In your proposed model, what does the following code do?
__var__ = 3
f.__var__ += 1
What about any of the following:
__var__ = 4
x = 3
__var__ = x*x
print h(2), h.__var__
def __radd__(self, other):
cls.__radd__ = __radd__
__created__ = Date(1, 1, 2004)
__expires__ = __created__ + Interval("1 year")
__now__ = time.time()
print l.__now__, l()
x = 3
__x__ = x
x = 4
print m(), m.__x__
def n(f, a):
__doc__ = gettext.gettext(f.__doc__)
__author__ = a.replace("@", " AT ").replace(".", " DOT ")
l = locals()
del l['f'], l['d'], l['a'], l['l']
import os as __os__
def q(): # BUG x doesn't get the proper metaclass in 2.3!
class __metaclass__(type): pass
class x: pass
# assert x's metaclass is __metaclass__
I gave it a few minutes thought, and I can't figure out a simple rule
that would *not* break code that happened to use __name__s as function
locals (since this has been allowed in all the ten years I've written
Python programs), would not add a new level of name lookup (lookup of
unqualified name on function object), would not introduce confusion
about when lines of code *in the function body* would be evaluated,
would not require that assignment statements be treated differently from
"def", "class", and "__import__" statements, etc, etc.
If you clear some or all of these things up, and turn it into a complete
proposal, wake me up.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
More information about the Python-list