3 ms·

> It's difficult to be obscure in Python. It's occasionally difficult to be obscure with Python syntax. It's not at all difficult to be obscure with anything

> It's difficult to be obscure in Python. It's occasionally difficult to be obscure with Python syntax. It's not at all difficult to be obscure with anything in Python above that level. Even then, if you do weird things with metaclasses or decorators, it's easy to be obscure with Python.

blasdel 17y ago
Decorators are an odd case -- I find that they make code dramatically clearer at the call-site, but that the decorator definitions get hairy fast (and get worse the more life-saving they are). They ended up being one of the best macro systems ever devised (they're applied at compile-time!).
- njharman 17y ago
  > they're applied at compile-time! I seriously don't under stand that statement. Decorators are callables that return callables, nothing else, nothing special. Decorator Syntax is just sugar. Decorators can be applied any time including runtime. I'm not even sure what you mean by "compile time" in regards to Python, import time?
  - blasdel 17y ago
    They're applied at parse-time, and they completely mask the def that they are applied to. Yes, the function being used as a decorator could just as easily be called at runtime, and that does break the similarity to macros somewhat.
    - njharman 17y ago
      Only decorator syntax happens somewhere around parse-time (which I call import time, but meh). > completely mask the def that they are applied to. @decorator reassign to the name of the def. But if there are other refs to that def they do not change and are not "masked". It is no different than assignment. You know that these two are identical, right? @foo def bar(): pass def bar(): pass bar = foo(bar) Also this is a perfectly valid decorater that doesn't mask the original func def deco(func): # do something terrible clever here return func decorator syntax != decorators is my main point. But by conflating the two I can begin to understand your statement.

blasdel 17y ago

Decorators are an odd case -- I find that they make code dramatically clearer at the call-site, but that the decorator definitions get hairy fast (and get worse the more life-saving they are). They ended up being one of the best macro systems ever devised (they're applied at compile-time!).

njharman 17y ago
> they're applied at compile-time! I seriously don't under stand that statement. Decorators are callables that return callables, nothing else, nothing special. Decorator Syntax is just sugar. Decorators can be applied any time including runtime. I'm not even sure what you mean by "compile time" in regards to Python, import time?
- blasdel 17y ago
  They're applied at parse-time, and they completely mask the def that they are applied to. Yes, the function being used as a decorator could just as easily be called at runtime, and that does break the similarity to macros somewhat.
  - njharman 17y ago
    Only decorator syntax happens somewhere around parse-time (which I call import time, but meh). > completely mask the def that they are applied to. @decorator reassign to the name of the def. But if there are other refs to that def they do not change and are not "masked". It is no different than assignment. You know that these two are identical, right? @foo def bar(): pass def bar(): pass bar = foo(bar) Also this is a perfectly valid decorater that doesn't mask the original func def deco(func): # do something terrible clever here return func decorator syntax != decorators is my main point. But by conflating the two I can begin to understand your statement.