Re: [Python-ideas] Problems (and solutions?) in writing decorators
All of your answers are true, > (Chris) > "my_decorator(x=foo)" is not going to look like "@my_decorator \n def foo". That’s one of the many ways that `decopatch` uses to perform the disambiguation, indeed. But that’s already the user helping the lib, not the other way round > (Christopher) > @something applied on def fun is exactly the same as something(fun) True. However applying decorator manually is already for advanced users, so users of a decopatche-d decorator will not mind calling something()(fun). In fact it is consistent with when they use it with arguments : something(arg)(fun). Another criterion is : how easy would it be to implement an inspect.is_decorator_call(frame) method returning True if and only if frame is the @ statement ? If that’s fairly easy, well, I’m pretty sure that this is good stuff. From a naïve user, not accustomed with the long history of this language, is very strange that an operator such as @ (the decorator one, not the other one) is completely not detectable by code, while there are so many hooks available in python for all other operators (+, -, etc.). Eventually that’s obviously your call, I’m just there to give feedback from what I see of the python libs development community. -- Sylvain De : Python-ideas De la part de Christopher Barker Envoyé : mercredi 20 mars 2019 06:50 À : Greg Ewing Cc : python-ideas Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators [External email: Use caution with links and attachments] Also: @something def fun(): ... Is exactly the same as: def fun() ... fun = something(fun) So you can’t make a distinction based whether a given usage is as a decoration. -CHB On Tue, Mar 19, 2019 at 12:26 PM Greg Ewing mailto:greg.ew...@canterbury.ac.nz>> wrote: Sylvain MARIE via Python-ideas wrote: > `my_decorator(foo)` when foo is a callable will always look like > `@my_decorator` applied to function foo, because that's how the language is > designed. I don't think it's worth doing anything to change that. Everywhere else in the language, there's a very clear distinction between 'foo' and 'foo()', and you confuse them at your peril. I don't see why decorators should be any different. -- Greg ___ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideas=02%7C01%7Csylvain.marie%40se.com%7C2e9308c9904c40f3702408d6acf7fc3a%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636886578423739625=%2BSHOm4PYwt6p%2F6Of69z0o19sH%2FimE4YsUFFtaEMlYCc%3D=0> Code of Conduct: http://python.org/psf/codeofconduct/<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F=02%7C01%7Csylvain.marie%40se.com%7C2e9308c9904c40f3702408d6acf7fc3a%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636886578423739625=uO%2Bq8AahHYhCVObE%2Fq3Tn%2BODC0vsdjWfX2niuuNgemE%3D=0> -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython __ This email has been scanned by the Symantec Email Security.cloud service. __ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
Also: @something def fun(): ... Is exactly the same as: def fun() ... fun = something(fun) So you can’t make a distinction based whether a given usage is as a decoration. -CHB On Tue, Mar 19, 2019 at 12:26 PM Greg Ewing wrote: > Sylvain MARIE via Python-ideas wrote: > > `my_decorator(foo)` when foo is a callable will always look like > > `@my_decorator` applied to function foo, because that's how the language > is > > designed. > > I don't think it's worth doing anything to change that. Everywhere > else in the language, there's a very clear distinction between > 'foo' and 'foo()', and you confuse them at your peril. I don't see > why decorators should be any different. > > -- > Greg > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
Sylvain MARIE via Python-ideas wrote: `my_decorator(foo)` when foo is a callable will always look like `@my_decorator` applied to function foo, because that's how the language is designed. I don't think it's worth doing anything to change that. Everywhere else in the language, there's a very clear distinction between 'foo' and 'foo()', and you confuse them at your peril. I don't see why decorators should be any different. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
On Wed, Mar 20, 2019 at 12:37 AM Sylvain MARIE via Python-ideas wrote: > > Stephen > > > If the answer is "maybe", IMO PyPI is the right solution for distribution. > > Very wise words, I understand this point. > However as of today it is *not* possible to write such a library in a > complete way, without an additional tool from the language itself. Trust me, > I tried very hard :). Indeed `my_decorator(foo)` when foo is a callable will > always look like `@my_decorator` applied to function foo, because that's how > the language is designed. So there is always one remaining ambiguous case to > cover, and I have to rely on some ugly tricks such as asking users for a > custom disambiguator. > Fair point. Though the custom disambiguator could be as simple as using a keyword argument - "my_decorator(x=foo)" is not going to look like "@my_decorator \n def foo". ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
Stephen > If the answer is "maybe", IMO PyPI is the right solution for distribution. Very wise words, I understand this point. However as of today it is *not* possible to write such a library in a complete way, without an additional tool from the language itself. Trust me, I tried very hard :). Indeed `my_decorator(foo)` when foo is a callable will always look like `@my_decorator` applied to function foo, because that's how the language is designed. So there is always one remaining ambiguous case to cover, and I have to rely on some ugly tricks such as asking users for a custom disambiguator. So if the decision is to let community-provided libraries like `decopatch` solve this problem, would you please consider providing us with the missing information? For example a new method in the `inspect` package could be `inspect.is_decorator_call(frame)`, that would return True if and only if the given frame is a decorator usage call as in `@my_decorator`. That piece would be enough - I would gladly take care of the rest in `decopatch`. Thanks for the feedback ! Sylvain -Message d'origine- De : Stephen J. Turnbull Envoyé : vendredi 15 mars 2019 04:56 À : Sylvain MARIE Cc : David Mertz ; python-ideas Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators [External email: Use caution with links and attachments] Sylvain MARIE via Python-ideas writes: > I totally understand your point of view. However on the other hand, > many > very popular open source projects out there have the opposite > point of > view and provide decorators that can seamlessly be used > with and without > arguments (pytest, attrs, click, etc.). So after a > while users get used > to this behavior and expect it from all > libraries. Making it easy to > implement is therefore something quite > important for developers not to > spend time on this useless > “feature”. That doesn't follow. You can also take it that "educating users to know the difference between a decorator and a decorator factory is therefore something quite important for developers not to spend time on this useless 'feature'." I'm not a fan of either position. I don't see why developers of libraries who want to provide this to their users shouldn't have "an easy way to do it", but I also don't see a good reason to encourage syntactic ambiguity by providing it in the standard library. I think this is a feature that belongs in the area of "you *could* do it, but *should* you?" If the answer is "maybe", IMO PyPI is the right solution for distribution. Steve -- Associate Professor Division of Policy and Planning Science https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturnbull.sk.tsukuba.ac.jp%2Fdata=02%7C01%7Csylvain.marie%40se.com%7C1c5b73f96ee240ef288608d6a8fa2030%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636882189569411152sdata=EcCuG%2Bad0oJoT1Fupd7086wkxHUPapCEKN2x3zDvCw0%3Dreserved=0 Faculty of Systems and Information Email: turnb...@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN __ This email has been scanned by the Symantec Email Security.cloud service. __ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
Sylvain MARIE via Python-ideas writes: > I totally understand your point of view. However on the other hand, > many very popular open source projects out there have the opposite > point of view and provide decorators that can seamlessly be used > with and without arguments (pytest, attrs, click, etc.). So after a > while users get used to this behavior and expect it from all > libraries. Making it easy to implement is therefore something quite > important for developers not to spend time on this useless > “feature”. That doesn't follow. You can also take it that "educating users to know the difference between a decorator and a decorator factory is therefore something quite important for developers not to spend time on this useless 'feature'." I'm not a fan of either position. I don't see why developers of libraries who want to provide this to their users shouldn't have "an easy way to do it", but I also don't see a good reason to encourage syntactic ambiguity by providing it in the standard library. I think this is a feature that belongs in the area of "you *could* do it, but *should* you?" If the answer is "maybe", IMO PyPI is the right solution for distribution. Steve -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnb...@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
Thanks David Sorry for not getting back to you earlier, I made a bunch of releases of makefun in the meantime. In particular I fixed a few bugs and added an equivalent of `functools.partial` . > One of the nice things in wrapt is that Dumpleton lets you use the same > decorator for functions, regular methods, static methods, and class methods. > Does yours handle that sort of "polymorphism"? It should, but I will check it thoroughly – I’ll let you know > I don't think I will want the specific with-or-without parens feature, since > it feels too implicit. Typing `@deco_factory()` really isn't too much work > for me to use the two characters extra. I totally understand your point of view. However on the other hand, many very popular open source projects out there have the opposite point of view and provide decorators that can seamlessly be used with and without arguments (pytest, attrs, click, etc.). So after a while users get used to this behavior and expect it from all libraries. Making it easy to implement is therefore something quite important for developers not to spend time on this useless “feature”. Kind regards Sylvain De : David Mertz Envoyé : mardi 12 mars 2019 19:15 À : Sylvain MARIE Cc : Steven D'Aprano ; python-ideas Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators [External email: Use caution with links and attachments] One of the nice things in wrapt is that Dumpleton lets you use the same decorator for functions, regular methods, static methods, and class methods. Does yours handle that sort of "polymorphism"? FWIW, thanks for the cool work with your libraries! I don't think I will want the specific with-or-without parens feature, since it feels too implicit. Typing `@deco_factory()` really isn't too much work for me to use the two characters extra. But given that I feel the option is an antipattern, I don't want to add core language features to make the pattern easier. Both you and Graham Dumpleton have found workarounds to get that behavior when it is wanted, but I don't want it to be "too easy." FWIW... I think I'd be tempted to use a metaclass approach so that both the class and instance are callable. The class would be called with a single function argument (i.e. a decorator), but if called with any other signature it would manufacture a callable instance that was parameterized by the initialization arguments (i.e. a decorator factory). Actually, I haven't looked at your actual code, maybe that's what you do. Best, David... On Tue, Mar 12, 2019 at 12:44 PM Sylvain MARIE mailto:sylvain.ma...@se.com>> wrote: Thanks David, > I did write the book _Functional Programming in Python_, so I'm not entirely > unfamiliar with function wrappers. Nice ! I did not realize ; good job here, congrats! ;) -- I carefully read the documentation you pointed at, https://wrapt.readthedocs.io/en/latest/decorators.html#decorators-with-optional-arguments<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwrapt.readthedocs.io%2Fen%2Flatest%2Fdecorators.html%23decorators-with-optional-arguments=02%7C01%7Csylvain.marie%40se.com%7Ceba5365e816845b8258808d6a716b054%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636880113229744945=hpuzWdGlzmfJypjI7tIMubrUYPaLN8MoS9BBlMIHGAY%3D=0> This is the example shown by the author: def with_optional_arguments(wrapped=None, myarg1=1, myarg2=2): if wrapped is None: return functools.partial(with_optional_arguments, myarg1=myarg1, myarg2=myarg2) @wrapt.decorator def wrapper(wrapped, instance, args, kwargs): return wrapped(*args, **kwargs) return wrapper(wrapped) As you can see: * the developer has to explicitly handle the no-parenthesis case (the first two lines of code). * And in the next lines of the doc you see his recommendations “For this to be used in this way, it is a requirement that the decorator arguments be supplied as keyword arguments. If using Python 3, the requirement to use keyword only arguments can again be enforced using the keyword only argument syntax.” * Finally, but this is just a comment: this is not “flat” mode but nested mode (the code returns a decorator that returns a function wrapper) So if I’m not misleading, the problem is not really solved. Or at least, not the way I would like the problem to be solved : it is solved here (a) only if the developer takes extra care and (b) reduces the way the decorator can be used (no positional args). This is precisely because I was frustrated by all these limitations that depend on the desired signature that I wrote decopatch. As a developer I do not want to care about which trick to use in which situation (mandatory args, optional args, var-positional args..). My decorators may change signature during the development cycle, and if
Re: [Python-ideas] Problems (and solutions?) in writing decorators
gt; readability !). > > To cover your concern: decopatch depends on makefun, so both come at the > same time when you install decopatch, and decopatch by default relies on > makefun when you use it in “double-flat” mode to create wrappers as > explained here https://smarie.github.io/python-decopatch/#even-simpler > > -- > > > > Thanks again for this discussion! It is challenging but it is necessary, > to make sure I did not answer a non-existent need ;) > > Kind regards > > > > -- > > Sylvain > > > > *De :* David Mertz > *Envoyé :* mardi 12 mars 2019 15:30 > *À :* Sylvain MARIE > *Cc :* Steven D'Aprano ; python-ideas < > python-ideas@python.org> > *Objet :* Re: [Python-ideas] Problems (and solutions?) in writing > decorators > > > > [External email: Use caution with links and attachments] > -- > > > > The documentation for wrapt mentions: > > > Decorators With Optional Arguments > > Although opinion can be mixed about whether the pattern is a good one, if > the decorator arguments all have default values, it is also possible to > implement decorators which have optional arguments. > > As Graham hints in his docs, I think repurposing decorator factories as > decorators is an antipattern. Explicit is better than implicit. > > > > While I *do* understands that what decotools and makefun do are > technically independent, I'm not sure I ever want them independently in > practice. I did write the book _Functional Programming in Python_, so I'm > not entirely unfamiliar with function wrappers. > > On Tue, Mar 12, 2019, 10:18 AM David Mertz wrote: > > The wrapt module I linked to (not funtools.wraps) provides all the > capabilities you mention since 2013. It allows mixed use of decorators as > decorator factories. It has a flat style. > > > > There are some minor API difference between your libraries and wrapt, but > the concept is very similar. Since yours is something new, I imagine you > perceive some win over what wrapt does. > > On Tue, Mar 12, 2019, 9:52 AM Sylvain MARIE wrote: > > David, Steven, > > Thanks for your interest ! > > As you probably know, decorators and function wrappers are *completely > different concepts*. A decorator can directly return the decorated function > (or class), it does not have to return a wrapper. Even more, it can > entirely replace the decorated item with something else (not even a > function or class!). Try it: it is possible to write a decorator to replace > a function with an integer, even though it is probably not quite useful :) > > `decopatch` helps you write decorators, whatever they are. It "just" > solves the annoying issue of having to handle the no-parenthesis and > with-parenthesis calls. In addition as a 'goodie', it proposes two > development styles: *nested* (you have to return a function) and *flat* > (you directly write what will happen when the decorator is applied to > something). > -- > Now about creating signature-preserving function wrappers (in a decorator, > or outside a decorator - again, that's not related). That use case is > supposed to be covered by functools.wrapt. Unfortunately as explained here > https://stackoverflow.com/questions/308999/what-does-functools-wraps-do/55102697#55102697 > <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F308999%2Fwhat-does-functools-wraps-do%2F55102697%2355102697=02%7C01%7Csylvain.marie%40se.com%7Ca7dee43a3bdf494e37c508d6a6f73f7d%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636879978186393926=Dmkd0Ld1HsuCJtJDCS6GDUgwH3GO66zwYMpZ9Ow%2B18k%3D=0> > this is not the case because with functools.wrapt: > - the wrapper code will execute even when the provided arguments are > invalid. > - the wrapper code cannot easily access an argument using its name, from > the received *args, **kwargs. Indeed one would have to handle all cases > (positional, keyword, default) and therefore to use something like > Signature.bind(). > > For this reason I proposed a replacement in `makefun`: > https://smarie.github.io/python-makefun/#signature-preserving-function-wrappers > <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsmarie.github.io%2Fpython-makefun%2F%23signature-preserving-function-wrappers=02%7C01%7Csylvain.marie%40se.com%7Ca7dee43a3bdf494e37c508d6a6f73f7d%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636879978186403936=SO319cmnKXiUK6Zek%2FSioHIhFfnQCZRpAF3kim84mv8%3D=0> > -- > Now bridging the gap. Of course a very interesting use cases for > decorators is to create decorators that create a signature-preserving > wrapper. It is possible to combine decopatch and makefun for this
Re: [Python-ideas] Problems (and solutions?) in writing decorators
Thanks David,
> I did write the book _Functional Programming in Python_, so I'm not entirely
> unfamiliar with function wrappers.
Nice ! I did not realize ; good job here, congrats! ;)
--
I carefully read the documentation you pointed at,
https://wrapt.readthedocs.io/en/latest/decorators.html#decorators-with-optional-arguments
This is the example shown by the author:
def with_optional_arguments(wrapped=None, myarg1=1, myarg2=2):
if wrapped is None:
return functools.partial(with_optional_arguments,
myarg1=myarg1, myarg2=myarg2)
@wrapt.decorator
def wrapper(wrapped, instance, args, kwargs):
return wrapped(*args, **kwargs)
return wrapper(wrapped)
As you can see:
* the developer has to explicitly handle the no-parenthesis case (the first
two lines of code).
* And in the next lines of the doc you see his recommendations “For this to
be used in this way, it is a requirement that the decorator arguments be
supplied as keyword arguments. If using Python 3, the requirement to use
keyword only arguments can again be enforced using the keyword only argument
syntax.”
* Finally, but this is just a comment: this is not “flat” mode but nested
mode (the code returns a decorator that returns a function wrapper)
So if I’m not misleading, the problem is not really solved. Or at least, not
the way I would like the problem to be solved : it is solved here (a) only if
the developer takes extra care and (b) reduces the way the decorator can be
used (no positional args). This is precisely because I was frustrated by all
these limitations that depend on the desired signature that I wrote decopatch.
As a developer I do not want to care about which trick to use in which
situation (mandatory args, optional args, var-positional args..). My decorators
may change signature during the development cycle, and if I frequently had to
change trick during development as I changed the signature - that is a bit
tiring.
--
Concerning creation of signature-preserving wrappers: @wrapt.decorator is not
signature preserving, I just checked it. You can check it with the following
experiment:
def dummy(wrapped):
@wrapt.decorator
def wrapper(wrapped, instance, args, kwargs):
print("wrapper called")
return wrapped(*args, **kwargs)
return wrapper(wrapped)
@dummy
def function(a, b):
pass
If you call
function(1)
you will see that “wrapper called” is displayed before the TypeError is raised…
The signature-preserving equivalent of @wrapt.decorator, @decorator.decorator,
is the source of inspiration for makefun. You can see `makefun` as a
generalization of the core of `decorator`.
--
> I'm not sure I ever want them (decopatch and makefun) independently in
> practice
I totally understand.
But some projects actually need makefun and not decopatch because their need is
different: they just want to create a function dynamically. This is low-level
tooling, really.
So at least now there is a clear separation of concerns (and dedicated issues
management/roadmap, which is also quite convenient. Not to mention readability
!).
To cover your concern: decopatch depends on makefun, so both come at the same
time when you install decopatch, and decopatch by default relies on makefun
when you use it in “double-flat” mode to create wrappers as explained here
https://smarie.github.io/python-decopatch/#even-simpler
--
Thanks again for this discussion! It is challenging but it is necessary, to
make sure I did not answer a non-existent need ;)
Kind regards
--
Sylvain
De : David Mertz
Envoyé : mardi 12 mars 2019 15:30
À : Sylvain MARIE
Cc : Steven D'Aprano ; python-ideas
Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators
[External email: Use caution with links and attachments]
The documentation for wrapt mentions:
Decorators With Optional Arguments
Although opinion can be mixed about whether the pattern is a good one, if the
decorator arguments all have default values, it is also possible to implement
decorators which have optional arguments.
As Graham hints in his docs, I think repurposing decorator factories as
decorators is an antipattern. Explicit is better than implicit.
While I *do* understands that what decotools and makefun do are technically
independent, I'm not sure I ever want them independently in practice. I did
write the book _Functional Programming in Python_, so I'm not entirely
unfamiliar with function wrappers.
On Tue, Mar 12, 2019, 10:18 AM David Mertz
mailto:me...@gnosis.cx>> wrote:
The wrapt module I linked to (not funtools.wraps) provides all the capabilities
you mention since 2013. It allows mixed use of decorators as decorator
factories. It has a flat style.
There are some minor API difference between your libraries and wrapt, but the
concept is very similar. Since yours is something new, I imagine you
Re: [Python-ideas] Problems (and solutions?) in writing decorators
The documentation for wrapt mentions: Decorators With Optional Arguments <https://wrapt.readthedocs.io/en/latest/decorators.html#decorators-with-optional-arguments> Although opinion can be mixed about whether the pattern is a good one, if the decorator arguments all have default values, it is also possible to implement decorators which have optional arguments. As Graham hints in his docs, I think repurposing decorator factories as decorators is an antipattern. Explicit is better than implicit. While I *do* understands that what decotools and makefun do are technically independent, I'm not sure I ever want them independently in practice. I did write the book _Functional Programming in Python_, so I'm not entirely unfamiliar with function wrappers. On Tue, Mar 12, 2019, 10:18 AM David Mertz wrote: > The wrapt module I linked to (not funtools.wraps) provides all the > capabilities you mention since 2013. It allows mixed use of decorators as > decorator factories. It has a flat style. > > There are some minor API difference between your libraries and wrapt, but > the concept is very similar. Since yours is something new, I imagine you > perceive some win over what wrapt does. > > On Tue, Mar 12, 2019, 9:52 AM Sylvain MARIE wrote: > >> David, Steven, >> >> Thanks for your interest ! >> >> As you probably know, decorators and function wrappers are *completely >> different concepts*. A decorator can directly return the decorated function >> (or class), it does not have to return a wrapper. Even more, it can >> entirely replace the decorated item with something else (not even a >> function or class!). Try it: it is possible to write a decorator to replace >> a function with an integer, even though it is probably not quite useful :) >> >> `decopatch` helps you write decorators, whatever they are. It "just" >> solves the annoying issue of having to handle the no-parenthesis and >> with-parenthesis calls. In addition as a 'goodie', it proposes two >> development styles: *nested* (you have to return a function) and *flat* >> (you directly write what will happen when the decorator is applied to >> something). >> -- >> Now about creating signature-preserving function wrappers (in a >> decorator, or outside a decorator - again, that's not related). That use >> case is supposed to be covered by functools.wrapt. Unfortunately as >> explained here >> https://stackoverflow.com/questions/308999/what-does-functools-wraps-do/55102697#55102697 >> this is not the case because with functools.wrapt: >> - the wrapper code will execute even when the provided arguments are >> invalid. >> - the wrapper code cannot easily access an argument using its name, from >> the received *args, **kwargs. Indeed one would have to handle all cases >> (positional, keyword, default) and therefore to use something like >> Signature.bind(). >> >> For this reason I proposed a replacement in `makefun`: >> https://smarie.github.io/python-makefun/#signature-preserving-function-wrappers >> -- >> Now bridging the gap. Of course a very interesting use cases for >> decorators is to create decorators that create a signature-preserving >> wrapper. It is possible to combine decopatch and makefun for this: >> https://smarie.github.io/python-decopatch/#3-creating-function-wrappers . >> Decopatch even proposes a "double-flat" development style where you >> directly write the wrapper body, as explained in the doc. >> >> Did I answer your questions ? >> Thanks again for the quick feedback ! >> Best, >> >> Sylvain >> >> -Message d'origine- >> De : Python-ideas >> De la part de Steven D'Aprano >> Envoyé : mardi 12 mars 2019 12:30 >> À : python-ideas@python.org >> Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators >> >> [External email: Use caution with links and attachments] >> >> >> >> >> >> On Tue, Mar 12, 2019 at 09:36:41AM +, Sylvain MARIE via Python-ideas >> wrote: >> >> > I therefore proposed >> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsma >> > rie.github.io%2Fpython-makefun%2Fdata=02%7C01%7Csylvain.marie%40s >> > e.com%7C579232e7e10e475314c708d6a6de9d23%7C6e51e1adc54b4b39b5980ffe9ae >> > 68fef%7C0%7C0%7C636879872385158085sdata=nB9p9V%2BJ7gk%2Fsc%2BA5%2 >> > Fekk35bnYGvmEFJyCXaLDyLm9I%3Dreserved=0 . In particular it >> > provides an equivalent of `@functools.wraps` that is truly >> > signature-preserving >> >> Tell us more about that please. I'm very
Re: [Python-ideas] Problems (and solutions?) in writing decorators
The wrapt module I linked to (not funtools.wraps) provides all the capabilities you mention since 2013. It allows mixed use of decorators as decorator factories. It has a flat style. There are some minor API difference between your libraries and wrapt, but the concept is very similar. Since yours is something new, I imagine you perceive some win over what wrapt does. On Tue, Mar 12, 2019, 9:52 AM Sylvain MARIE wrote: > David, Steven, > > Thanks for your interest ! > > As you probably know, decorators and function wrappers are *completely > different concepts*. A decorator can directly return the decorated function > (or class), it does not have to return a wrapper. Even more, it can > entirely replace the decorated item with something else (not even a > function or class!). Try it: it is possible to write a decorator to replace > a function with an integer, even though it is probably not quite useful :) > > `decopatch` helps you write decorators, whatever they are. It "just" > solves the annoying issue of having to handle the no-parenthesis and > with-parenthesis calls. In addition as a 'goodie', it proposes two > development styles: *nested* (you have to return a function) and *flat* > (you directly write what will happen when the decorator is applied to > something). > -- > Now about creating signature-preserving function wrappers (in a decorator, > or outside a decorator - again, that's not related). That use case is > supposed to be covered by functools.wrapt. Unfortunately as explained here > https://stackoverflow.com/questions/308999/what-does-functools-wraps-do/55102697#55102697 > this is not the case because with functools.wrapt: > - the wrapper code will execute even when the provided arguments are > invalid. > - the wrapper code cannot easily access an argument using its name, from > the received *args, **kwargs. Indeed one would have to handle all cases > (positional, keyword, default) and therefore to use something like > Signature.bind(). > > For this reason I proposed a replacement in `makefun`: > https://smarie.github.io/python-makefun/#signature-preserving-function-wrappers > -- > Now bridging the gap. Of course a very interesting use cases for > decorators is to create decorators that create a signature-preserving > wrapper. It is possible to combine decopatch and makefun for this: > https://smarie.github.io/python-decopatch/#3-creating-function-wrappers . > Decopatch even proposes a "double-flat" development style where you > directly write the wrapper body, as explained in the doc. > > Did I answer your questions ? > Thanks again for the quick feedback ! > Best, > > Sylvain > > -Message d'origine- > De : Python-ideas > De la part de Steven D'Aprano > Envoyé : mardi 12 mars 2019 12:30 > À : python-ideas@python.org > Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators > > [External email: Use caution with links and attachments] > > > > > > On Tue, Mar 12, 2019 at 09:36:41AM +, Sylvain MARIE via Python-ideas > wrote: > > > I therefore proposed > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsma > > rie.github.io%2Fpython-makefun%2Fdata=02%7C01%7Csylvain.marie%40s > > e.com%7C579232e7e10e475314c708d6a6de9d23%7C6e51e1adc54b4b39b5980ffe9ae > > 68fef%7C0%7C0%7C636879872385158085sdata=nB9p9V%2BJ7gk%2Fsc%2BA5%2 > > Fekk35bnYGvmEFJyCXaLDyLm9I%3Dreserved=0 . In particular it > > provides an equivalent of `@functools.wraps` that is truly > > signature-preserving > > Tell us more about that please. I'm very interested in getting decorators > preserve the original signature. > > > -- > Steven > ___ > Python-ideas mailing list > Python-ideas@python.org > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideasdata=02%7C01%7Csylvain.marie%40se.com%7C579232e7e10e475314c708d6a6de9d23%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636879872385158085sdata=XcYfEginmDF7kIpGGA0XxDZKpUn9e4p2zPFk7UAruYg%3Dreserved=0 > Code of Conduct: > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2Fdata=02%7C01%7Csylvain.marie%40se.com%7C579232e7e10e475314c708d6a6de9d23%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636879872385158085sdata=20ZrtVQZbpQ54c96veSXIOfEK7rKy0ggj0omTZg3ri8%3Dreserved=0 > > __ > This email has been scanned by the Symantec Email Security.cloud service. > __ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
David I realize that you were pointing at the 'wrapt' library not the functools.wrapt library. >From what I have tried with that library, it does not solve the issue solved >with decopatch. Sylvain -Message d'origine- De : Sylvain MARIE Envoyé : mardi 12 mars 2019 14:53 À : Steven D'Aprano ; python-ideas@python.org; David Mertz Objet : RE: [Python-ideas] Problems (and solutions?) in writing decorators David, Steven, Thanks for your interest ! As you probably know, decorators and function wrappers are *completely different concepts*. A decorator can directly return the decorated function (or class), it does not have to return a wrapper. Even more, it can entirely replace the decorated item with something else (not even a function or class!). Try it: it is possible to write a decorator to replace a function with an integer, even though it is probably not quite useful :) `decopatch` helps you write decorators, whatever they are. It "just" solves the annoying issue of having to handle the no-parenthesis and with-parenthesis calls. In addition as a 'goodie', it proposes two development styles: *nested* (you have to return a function) and *flat* (you directly write what will happen when the decorator is applied to something). -- Now about creating signature-preserving function wrappers (in a decorator, or outside a decorator - again, that's not related). That use case is supposed to be covered by functools.wrapt. Unfortunately as explained here https://stackoverflow.com/questions/308999/what-does-functools-wraps-do/55102697#55102697 this is not the case because with functools.wrapt: - the wrapper code will execute even when the provided arguments are invalid. - the wrapper code cannot easily access an argument using its name, from the received *args, **kwargs. Indeed one would have to handle all cases (positional, keyword, default) and therefore to use something like Signature.bind(). For this reason I proposed a replacement in `makefun`: https://smarie.github.io/python-makefun/#signature-preserving-function-wrappers -- Now bridging the gap. Of course a very interesting use cases for decorators is to create decorators that create a signature-preserving wrapper. It is possible to combine decopatch and makefun for this: https://smarie.github.io/python-decopatch/#3-creating-function-wrappers . Decopatch even proposes a "double-flat" development style where you directly write the wrapper body, as explained in the doc. Did I answer your questions ? Thanks again for the quick feedback ! Best, Sylvain -Message d'origine- De : Python-ideas De la part de Steven D'Aprano Envoyé : mardi 12 mars 2019 12:30 À : python-ideas@python.org Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators [External email: Use caution with links and attachments] On Tue, Mar 12, 2019 at 09:36:41AM +, Sylvain MARIE via Python-ideas wrote: > I therefore proposed > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsma > rie.github.io%2Fpython-makefun%2Fdata=02%7C01%7Csylvain.marie%40s > e.com%7C579232e7e10e475314c708d6a6de9d23%7C6e51e1adc54b4b39b5980ffe9ae > 68fef%7C0%7C0%7C636879872385158085sdata=nB9p9V%2BJ7gk%2Fsc%2BA5%2 > Fekk35bnYGvmEFJyCXaLDyLm9I%3Dreserved=0 . In particular it > provides an equivalent of `@functools.wraps` that is truly > signature-preserving Tell us more about that please. I'm very interested in getting decorators preserve the original signature. -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideasdata=02%7C01%7Csylvain.marie%40se.com%7C579232e7e10e475314c708d6a6de9d23%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636879872385158085sdata=XcYfEginmDF7kIpGGA0XxDZKpUn9e4p2zPFk7UAruYg%3Dreserved=0 Code of Conduct: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2Fdata=02%7C01%7Csylvain.marie%40se.com%7C579232e7e10e475314c708d6a6de9d23%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636879872385158085sdata=20ZrtVQZbpQ54c96veSXIOfEK7rKy0ggj0omTZg3ri8%3Dreserved=0 __ This email has been scanned by the Symantec Email Security.cloud service. __ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
David, Steven, Thanks for your interest ! As you probably know, decorators and function wrappers are *completely different concepts*. A decorator can directly return the decorated function (or class), it does not have to return a wrapper. Even more, it can entirely replace the decorated item with something else (not even a function or class!). Try it: it is possible to write a decorator to replace a function with an integer, even though it is probably not quite useful :) `decopatch` helps you write decorators, whatever they are. It "just" solves the annoying issue of having to handle the no-parenthesis and with-parenthesis calls. In addition as a 'goodie', it proposes two development styles: *nested* (you have to return a function) and *flat* (you directly write what will happen when the decorator is applied to something). -- Now about creating signature-preserving function wrappers (in a decorator, or outside a decorator - again, that's not related). That use case is supposed to be covered by functools.wrapt. Unfortunately as explained here https://stackoverflow.com/questions/308999/what-does-functools-wraps-do/55102697#55102697 this is not the case because with functools.wrapt: - the wrapper code will execute even when the provided arguments are invalid. - the wrapper code cannot easily access an argument using its name, from the received *args, **kwargs. Indeed one would have to handle all cases (positional, keyword, default) and therefore to use something like Signature.bind(). For this reason I proposed a replacement in `makefun`: https://smarie.github.io/python-makefun/#signature-preserving-function-wrappers -- Now bridging the gap. Of course a very interesting use cases for decorators is to create decorators that create a signature-preserving wrapper. It is possible to combine decopatch and makefun for this: https://smarie.github.io/python-decopatch/#3-creating-function-wrappers . Decopatch even proposes a "double-flat" development style where you directly write the wrapper body, as explained in the doc. Did I answer your questions ? Thanks again for the quick feedback ! Best, Sylvain -Message d'origine- De : Python-ideas De la part de Steven D'Aprano Envoyé : mardi 12 mars 2019 12:30 À : python-ideas@python.org Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators [External email: Use caution with links and attachments] On Tue, Mar 12, 2019 at 09:36:41AM +, Sylvain MARIE via Python-ideas wrote: > I therefore proposed > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsma > rie.github.io%2Fpython-makefun%2Fdata=02%7C01%7Csylvain.marie%40s > e.com%7C579232e7e10e475314c708d6a6de9d23%7C6e51e1adc54b4b39b5980ffe9ae > 68fef%7C0%7C0%7C636879872385158085sdata=nB9p9V%2BJ7gk%2Fsc%2BA5%2 > Fekk35bnYGvmEFJyCXaLDyLm9I%3Dreserved=0 . In particular it > provides an equivalent of `@functools.wraps` that is truly > signature-preserving Tell us more about that please. I'm very interested in getting decorators preserve the original signature. -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideasdata=02%7C01%7Csylvain.marie%40se.com%7C579232e7e10e475314c708d6a6de9d23%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636879872385158085sdata=XcYfEginmDF7kIpGGA0XxDZKpUn9e4p2zPFk7UAruYg%3Dreserved=0 Code of Conduct: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2Fdata=02%7C01%7Csylvain.marie%40se.com%7C579232e7e10e475314c708d6a6de9d23%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636879872385158085sdata=20ZrtVQZbpQ54c96veSXIOfEK7rKy0ggj0omTZg3ri8%3Dreserved=0 __ This email has been scanned by the Symantec Email Security.cloud service. __ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
On Tue, Mar 12, 2019 at 09:36:41AM +, Sylvain MARIE via Python-ideas wrote: > I therefore proposed > https://smarie.github.io/python-makefun/ . In particular it provides > an equivalent of `@functools.wraps` that is truly signature-preserving Tell us more about that please. I'm very interested in getting decorators preserve the original signature. -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
What advantage do you perceive decopatch to have over wrapt? ( https://github.com/GrahamDumpleton/wrapt) On Tue, Mar 12, 2019, 5:37 AM Sylvain MARIE via Python-ideas < python-ideas@python.org> wrote: > Dear python enthusiasts, > > Writing python decorators is indeed quite a tideous process, in particular > when you wish to add arguments, and in particular in two cases : all > optional arguments, and one mandatory argument. Indeed in these two cases > there is a need to disambiguate between no-parenthesis and with-parenthesis > usage. > > After having struggled with this pattern for two years in various open > source and industrial projects, I ended up writing a library to hopefully > solve this once and for all: https://smarie.github.io/python-decopatch/ . > It is extensively tested (203 tests) against many combinations of > signature/calls. > I would gladly appreciate any feedback ! > > Please note that there is a "PEP proposal draft" in the project page > because I belive that the best a library can do will always be a poor > workaround, where the interpreter or stdlib could really fix it properly. > Sorry for not providing too much implementation details in that page, my > knowledge of the python interpreter is unfortunately quite limited. > > -- > > Finally there is an additional topic around decorators : people tend to > believe that decorators and function wrappers are the same, which is > absolutely not the case. I used the famous `decorator` lib in many projects > but I was not satisfied because it was solving both issues at the same > time, maintaining the confusion. I therefore proposed > https://smarie.github.io/python-makefun/ . In particular it provides an > equivalent of `@functools.wraps` that is truly signature-preserving (based > on the same recipe than `decorator`). > Once again, any feedback would be gladly appreciated ! > > Kind regards > > Sylvain > > -Message d'origine- > De : Python-ideas > De la part de Greg Ewing > Envoyé : vendredi 26 octobre 2018 00:04 > À : python-ideas > Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators > > [External email: Use caution with links and attachments] > > > > > > Jonathan Fine wrote: > > I also find writing decorators a bit > > hard. It seems to be something I have to learn anew each time I do it. > > Particularly for the pattern > > > > @deco(arg1, arg2) def fn(arg3, arg4): > > # function body > > > > Perhaps doing something with partial might help here. Anyone here > > interested in exploring this? > > > > I can't think of a way that partial would help. But would you find it > easier if you could do something like this? > > class deco(Decorator): > > def __init__(self, arg1, arg2): > self.arg1 = arg1 > self.arg2 = arg2 > > def invoke(self, func, arg3, arg4): > # function body > > Implementation: > > class Decorator: > > def __call__(self, func): > self._wrapped_function = func > return self._wrapper > > def _wrapper(self, *args, **kwds): > return self.invoke(self._wrapped_function, *args, **kwds) > > -- > Greg > ___ > Python-ideas mailing list > Python-ideas@python.org > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideasdata=02%7C01%7Csylvain.marie%40se.com%7C295cecd58fc3461f42c108d63ac5e03e%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C63676101605889sdata=Z8OET1CZZWnmN5czi0rZ1X57%2FDd4a9IDbbSujsDNWzk%3Dreserved=0 > Code of Conduct: > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2Fdata=02%7C01%7Csylvain.marie%40se.com%7C295cecd58fc3461f42c108d63ac5e03e%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C63676101615894sdata=u0hvM5cR%2BR1Vni%2BV48WoNF%2FpriCaOG5%2BFAXayaTGsYY%3Dreserved=0 > > __ > This email has been scanned by the Symantec Email Security.cloud service. > __ > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
Dear python enthusiasts, Writing python decorators is indeed quite a tideous process, in particular when you wish to add arguments, and in particular in two cases : all optional arguments, and one mandatory argument. Indeed in these two cases there is a need to disambiguate between no-parenthesis and with-parenthesis usage. After having struggled with this pattern for two years in various open source and industrial projects, I ended up writing a library to hopefully solve this once and for all: https://smarie.github.io/python-decopatch/ . It is extensively tested (203 tests) against many combinations of signature/calls. I would gladly appreciate any feedback ! Please note that there is a "PEP proposal draft" in the project page because I belive that the best a library can do will always be a poor workaround, where the interpreter or stdlib could really fix it properly. Sorry for not providing too much implementation details in that page, my knowledge of the python interpreter is unfortunately quite limited. -- Finally there is an additional topic around decorators : people tend to believe that decorators and function wrappers are the same, which is absolutely not the case. I used the famous `decorator` lib in many projects but I was not satisfied because it was solving both issues at the same time, maintaining the confusion. I therefore proposed https://smarie.github.io/python-makefun/ . In particular it provides an equivalent of `@functools.wraps` that is truly signature-preserving (based on the same recipe than `decorator`). Once again, any feedback would be gladly appreciated ! Kind regards Sylvain -Message d'origine- De : Python-ideas De la part de Greg Ewing Envoyé : vendredi 26 octobre 2018 00:04 À : python-ideas Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators [External email: Use caution with links and attachments] Jonathan Fine wrote: > I also find writing decorators a bit > hard. It seems to be something I have to learn anew each time I do it. > Particularly for the pattern > > @deco(arg1, arg2) def fn(arg3, arg4): > # function body > > Perhaps doing something with partial might help here. Anyone here > interested in exploring this? > I can't think of a way that partial would help. But would you find it easier if you could do something like this? class deco(Decorator): def __init__(self, arg1, arg2): self.arg1 = arg1 self.arg2 = arg2 def invoke(self, func, arg3, arg4): # function body Implementation: class Decorator: def __call__(self, func): self._wrapped_function = func return self._wrapper def _wrapper(self, *args, **kwds): return self.invoke(self._wrapped_function, *args, **kwds) -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideasdata=02%7C01%7Csylvain.marie%40se.com%7C295cecd58fc3461f42c108d63ac5e03e%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C63676101605889sdata=Z8OET1CZZWnmN5czi0rZ1X57%2FDd4a9IDbbSujsDNWzk%3Dreserved=0 Code of Conduct: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2Fdata=02%7C01%7Csylvain.marie%40se.com%7C295cecd58fc3461f42c108d63ac5e03e%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C63676101615894sdata=u0hvM5cR%2BR1Vni%2BV48WoNF%2FpriCaOG5%2BFAXayaTGsYY%3Dreserved=0 __ This email has been scanned by the Symantec Email Security.cloud service. __ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Problems (and solutions?) in writing decorators
Jonathan Fine wrote: I also find writing decorators a bit hard. It seems to be something I have to learn anew each time I do it. Particularly for the pattern @deco(arg1, arg2) def fn(arg3, arg4): > # function body Perhaps doing something with partial might help here. Anyone here interested in exploring this? I can't think of a way that partial would help. But would you find it easier if you could do something like this? class deco(Decorator): def __init__(self, arg1, arg2): self.arg1 = arg1 self.arg2 = arg2 def invoke(self, func, arg3, arg4): # function body Implementation: class Decorator: def __call__(self, func): self._wrapped_function = func return self._wrapper def _wrapper(self, *args, **kwds): return self.invoke(self._wrapped_function, *args, **kwds) -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Problems (and solutions?) in writing decorators
Was: Return for assignment blocks Anders Hovmöller wrote: > Personally I often just copy paste an existing decorator and then tweak it > instead of writing from scratch because it's too confusing and error prone to > do that. Thank you, Anders, for your honesty. I also find writing decorators a bit hard. It seems to be something I have to learn anew each time I do it. Particularly for the pattern @deco(arg1, arg2) def fn(arg3, arg4): # function body Perhaps doing something with partial might help here. Anyone here interested in exploring this? -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
