> Interestingly, this syntax also works to do decoration, though it's not a > syntax that was ever proposed for that. e.g.: > > foo = classmethod(foo) where: > def foo(cls,x,y,z): > # etc.
This requires you to write foo three times, which defeats at least half of the purpose of decorators.
Well, you could do 'foo = classmethod(x) where: def x(...)', but that *is* kind of kludgy. I'm just suggesting that if 'where:' had existed before decorators, people might have griped about the three-time typing or kludged around it, but there wouldn't likely have been strong support for creating a syntax "just" for decorators.
Indeed, if somebody had proposed this syntax during the decorator debates I would have supported it, but of course Bob Ippolito (whose PyObjC use cases involve really long function names) might have disagreed.
> foo = property(get_foo,set_foo) where:
> def get_foo(self):
> # ...
> def set_foo(self):
> # ...
>
> I don't mind @decorators, of course, but maybe they wouldn't be needed here.
As I said before, I'm not sure why keeping get_foo etc. out of the class namespace is such a big deal.
That's a relatively minor thing, compared to being able to logically group them with the property, which I think enhances readability, even more than the sometimes-proposed '@property.getter' and '@property.setter' decorators.
Anyway, just to be clear, I don't personally think 'where:' is needed in Python 2.x; lambda and decorators suffice for all but the most Twisted use cases. ;) I was just viewing it as a potential alternative to lambda in Py3K.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
