Case Statements

[Chris Angelico]

On Thu, Mar 17, 2016 at 12:54 PM, Steven D'Aprano <steve at 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