Wemake-python-styleguide: python3.9: forbid anything, but dotted names inside decorators

[sobolevn]

Rule 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!

Related: https://www.python.org/dev/peps/pep-0614/

[lewisacidic]

I would argue the PEP does provide a good example use case:

@buttons[0].clicked.connect
def spam():
    ...

vs having to do

button_0 = buttons[0]

@button_0.clicked.connect
def spam():
    ...

The second one looks confusing and hacky in my opinion, and I'm glad the PEP was accepted.

That said, I agree complex decorator expressions would destroy readability. Perhaps requiring a low complexity for decorator expressions might be a more measured solution than a blanket ban?

[sobolevn]

@lewisacidic I am glad that you brought this up!

Let me explain the problem in this PEP example.

When you write @buttons[0].clicked.connect you are really making several very important assumptions.

First, buttons[0] is really special. Because it is the only one that is connected to this function. So, it should have a name! And a clear one. Not button_0. Let's say that it is a registration-related button. So, @registration_button.clicked.connect is way more readable @buttons[0].clicked.connect

We can also use the alternative approach:

def spam():
    ...

buttons[0].clicked.connect(spam)
# or even `for button in buttons: button.clicked.connect(spam)`

That's why we won't allow this syntax. It is broken by the very core idea.

[lewisacidic]

I agree it is not a fantastic example, the variable name button_0 is bad, and button[0].anything smells. But what if you have a dictionary of buttons:

@buttons["registration"].clicked.connect
def spam():
     ...

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!

[ruwaid4]

Hello, could i take this one?

[sobolevn]

Nope, sorry. python3.9 is not even released. Let's wait 🙂