[carapace]

Thanks for posting that, I was puzzled too.

- - - -

I can't help myself. The example in the PEP:

    buttons = [QPushButton(f'Button {i}') for i in range(10)]

    # Do stuff with the list of buttons...

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

    ...

seems silly to me, I would have done something like:

    connect_button = lambda n: buttons[n].clicked.connect

    @connect_button(0)
    def spam():
        ...

I was a huge Python fan but these days I really feel that Python is being improved to death.

[L3viathan]

I think this specific change is making Python simpler. It was a weird exception that previously only a limited subset of all possible expressions could be used as a decorator. Now the rule is just "you can decorate a function or class with any expression".

[carapace]

You're right, this is simpler and more regular, but I don't feel that's enough of an improvement to warrant the changes required to implement it.

(The C Python interpreter is not the only code that relies on understanding Python code. For example, I used to use a set of tools called "Snakefood" but they aren't currently maintained. So as Python changes and changes they become less and less useful.)

In the PEP itself, under "How To Teach This" it even says, "the average Python programmer is likely unaware that the current restriction even exists."

And the "good example of code ... that would become more readable, idiomatic, and maintainable if the existing restrictions were relaxed." is not a good example. IMO (as I hinted at above) it's an example of code written by a programmer who is less well-practiced than one might hope.

The "Identity function hack" is part-way to the connect_button() function but it stops short at a goofy, ugly strawman function (that shadows '_'!? Why?) rather than factoring out the common parts of the expressions. Rookie mistake, eh?

(The eval hack is clever but stupid.)

So to me this seems like a poorly justified change that solves a non-problem.

[mlyle]

Conversely, it gets easier to write outside tools that interact with Python code by removing corner cases and simplifying the grammar.

> In the PEP itself, under "How To Teach This" it even says, "the average Python programmer is likely unaware that the current restriction even exists."

Yup, and that's terrible. It means people are likely to trip over it.

[carapace]

> Conversely, it gets easier to write outside tools that interact with Python code by removing corner cases and simplifying the grammar.

That sounds like a false economy to me. A one time small savings of developer effort (implementing the old grammar rule for decorators wasn't onerous?) to permit foolish and unnecessary intricacies among the laity.

> It means people are likely to trip over it.

Only if they are attempting to do something foolish. (Who puts whole expressions in a decorator!?)

- - - -

Tell you what, you go find examples where people have tripped over it in the past and I'll code golf them to see if I can come up with something idiomatic and simpler. Does that sound like fun to you? ("Cause it does to me. Candy!)