[Python-ideas] Problems (and solutions?) in writing decorators
sylvain.marie at se.com
Tue Mar 19 09:33:15 EDT 2019
> 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 !
De : Stephen J. Turnbull <turnbull.stephen.fw at u.tsukuba.ac.jp>
Envoyé : vendredi 15 mars 2019 04:56
À : Sylvain MARIE <sylvain.marie at se.com>
Cc : David Mertz <mertz at gnosis.cx>; python-ideas <python-ideas at python.org>
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.
Associate Professor Division of Policy and Planning Science
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fturnbull.sk.tsukuba.ac.jp%2F&data=02%7C01%7Csylvain.marie%40se.com%7C1c5b73f96ee240ef288608d6a8fa2030%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636882189569411152&sdata=EcCuG%2Bad0oJoT1Fupd7086wkxHUPapCEKN2x3zDvCw0%3D&reserved=0 Faculty of Systems and Information
Email: turnbull at 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.
More information about the Python-ideas