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.





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]





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.




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.

Python-ideas mailing list
Code of Conduct:


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 service.