python3.9: forbid anything, but dotted names inside decorators
See original GitHub issueRule request
Thesis
After python3.9
we would be able to use this as a decorator:
@decorator_generator[start[5]:end_generator(start[5], end[-1])](gen=DecEnum.generate, **options).build() / overloaded_operator()
def some():
...
WHAT?! WHY?!
We need to add a rule that forbids it.
Only names, attributes, and calls should be allowed after @
Reasoning
This is an extra complexity that is totally not required. I don’t have any valid use-cases for this. Use variables, functions, attributes. It is not that hard!
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Built-in Functions — Python 3.11.1 documentation
The Python interpreter has a number of functions and types built into it that are always available. They are listed here in alphabetical...
Read more >PEP 614 – Relaxing Grammar Restrictions On Decorators
Python currently requires that all decorators consist of a dotted name, optionally followed by a single call. This PEP proposes removing ...
Read more >3. Data model — Python 3.11.1 documentation
This object is accessed through the built-in name None . It is used to signify the absence of a value in many situations,...
Read more >What's New In Python 3.10 — Python 3.11.1 documentation
However, the singletons True , False and None are compared by identity. Named constants may be used in patterns. These named constants must...
Read more >Glossary — Python 3.11.1 documentation
Python comes with many built-in ABCs for data structures (in the ... associated with an object which is usually referenced by name using...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Nope, sorry. python3.9 is not even released. Let’s wait 🙂
I agree it is not a fantastic example, the variable name
button_0
is bad, andbutton[0].anything
smells. But what if you have a dictionary of buttons:I do think index notation is more succinct and doesn’t compromise readability in some contexts.
In any case, thanks for clarifying the reasoning behind this issue: it’s a matter of enforcing explicit variable naming, rather than avoiding messy expressions as decorators which was my interpretation from the initial comment. I’ll respectfully probably disable this rule as and when it lands.
Off topic, but thanks for your work on this library!