Are decorators really that different from metaclasses...
Jeff Epler
jepler at unpythonic.net
Sun Aug 29 22:42:46 EDT 2004
In your proposed model, what does the following code do?
def f():
__var__ = 3
return __var__
f.__var__ += 1
print f()
What about any of the following:
def g():
if True:
__var__ = 4
print g.__var__
x = 3
def h(x):
__var__ = x*x
return x*x
print h(2), h.__var__
def j(cls):
def __radd__(self, other):
return self.__add__(other)
cls.__radd__ = __radd__
def k(x):
__created__ = Date(1, 1, 2004)
__expires__ = __created__ + Interval("1 year")
def l(x):
__now__ = time.time()
return __now__
print l.__now__, l()
x = 3
def m():
__x__ = x
return __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']
f.__dict__.__update__(l)
def p():
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.
Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20040829/463d1bb5/attachment.sig>
More information about the Python-list
mailing list