On Thu, Mar 17, 2016 at 12:54 PM, Steven D'Aprano <st...@pearwood.info> wrote: > On Thu, 17 Mar 2016 11:31 am, Chris Angelico wrote: > >> Yes... in theory. But try rewriting my example to avoid decorator >> syntax. It won't work, because of this line: >> >> orig = globals()[cls.__name__] > > That's a nasty, dirty piece of code, and I hope you are thoroughly ashamed > of having written it :-)
No, I am not ashamed of having written it. The file it's in is called "evil.py" and it exists specifically to showcase bad uses of decorators :) >> It depends on the decorator being run before the name actually gets >> bound - which means the previous class is available to the decorator. >> You can't do that without decorator syntax, or messing around with >> multiple names. > > > I wouldn't want to rely on it working with decorator syntax either. Even if > it does now, I'm not sure that's a language guarantee. That's the thing, though. It's not a guarantee, yet it does work in every Python interpreter that I tried it in. And that puts it on par with dictionary iteration order - people will end up depending on it. So while it's definitely not wise to deliberately depend on this (and believe you me, there is nothing like this in any of my production code!!), it's entirely possible that there's code out in the wild that unwittingly does. Anyway, it's just a fun thing to bring out when people start talking about decorator equivalence. And even experienced Pythonistas can be confused by it - I certainly was, when I first saw it. Fun fun. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
