7 ms·

The article is interesting but really if you want to make decorators easier to understand don't introduce another layer of abstraction, use a class. The __init_

by j1z0 13y ago

The article is interesting but really if you want to make decorators easier to understand don't introduce another layer of abstraction, use a class. The __init__ function handles the decorator arguments just like you would expect from a class. The __call__ function is called when the decorator is called, just return your new function and well; your done. And it's all pretty straight forward.

Suor 13y ago
You will still need a wrapper function and update it's metadata. Which is even more boilerplate. Or you can hide that in base Decorator class, but then we'll back to another layer of abstraction. So it's either more boilerplate or more abstraction. Choose exactly one.
- j1z0 13y ago
  Well if you use functools like you started with in your lead up examples your talking about what two lines of boilerplate (functools decorator and function definition)? Personally I often times just add the four lines of boiler plate and forgo functools.... Look I'm not saying that your library is a bad idea; Its neat, in fact it seems to handle a few thing better than the more well known decorator library does. ( Out of curiosity though how about the functions signature, I think functools doesn't maintain the original functions signature but I think decorator does, what does funcy do? ) For me personally I feel its better to have the decorator all in one place where you can see everything that is going on, and making it a class makes it pretty straight forward to understand.
  - Suor 13y ago
    funcy doesn't preserve function signature. The only way for now to do this is to use exec, e.g. compile code from source or AST, which I choose to avoid.
ekimekim 13y ago
I tend to see functions as merely a special-case of classes anyway. In a certain mindset, I consider this: def foo(...): ... shorthand for this: class Foo(object): def __call__(self, ...): ... foo = Foo() And so, if the situation warrants, I may expand some function to instead be a full class, take init arguments, etc. But commonly I don't. Even the case of a (not too complex) decorator I feels is handled nicer by closure than by instance variables.

by j1z0 13y ago

Suor 13y ago

You will still need a wrapper function and update it's metadata. Which is even more boilerplate. Or you can hide that in base Decorator class, but then we'll back to another layer of abstraction. So it's either more boilerplate or more abstraction. Choose exactly one.

j1z0 13y ago
Well if you use functools like you started with in your lead up examples your talking about what two lines of boilerplate (functools decorator and function definition)? Personally I often times just add the four lines of boiler plate and forgo functools.... Look I'm not saying that your library is a bad idea; Its neat, in fact it seems to handle a few thing better than the more well known decorator library does. ( Out of curiosity though how about the functions signature, I think functools doesn't maintain the original functions signature but I think decorator does, what does funcy do? ) For me personally I feel its better to have the decorator all in one place where you can see everything that is going on, and making it a class makes it pretty straight forward to understand.
- Suor 13y ago
  funcy doesn't preserve function signature. The only way for now to do this is to use exec, e.g. compile code from source or AST, which I choose to avoid.

ekimekim 13y ago

I tend to see functions as merely a special-case of classes anyway. In a certain mindset, I consider this: def foo(...): ... shorthand for this: class Foo(object): def __call__(self, ...): ... foo = Foo() And so, if the situation warrants, I may expand some function to instead be a full class, take init arguments, etc. But commonly I don't. Even the case of a (not too complex) decorator I feels is handled nicer by closure than by instance variables.