This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients Guido.van.Rossum, dirn, eric.araujo, eric.smith, eric.snow, gvanrossum, james, ncoghlan, peyton
Date 2013-11-21.03:32:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CADiSq7evVVJD0bzb6iK35oucsUr3Vti9faN-83nkdi9RnemsCg@mail.gmail.com>
In-reply-to <1384997782.98.0.228351558707.issue19660@psf.upfronthosting.co.za>
Content
Yes, a PEP for 3.5 on this will be valuable, whether it's accepted or not
(although I personally favour moving these restrictions out of the compiler
and into the PEP 8 style guide).

If I recall the past python-ideas threads correctly, the main objections to
the current syntax restrictions were:

- you can't look up decorators through a registry by default, since
"@registry[name]" is disallowed
- it's not really a limitation anyway, since a pass through function still
lets you write whatever you want:

    def deco(x): return x

    @deco(registry[name])
    def f(): ...

Now that the precedent of keeping decorator expressions simple has been
well and truly established, simplification of the grammar is the main
reason removing the special casing of decorator syntax from the compilation
toolchain appeals to me.
History
Date User Action Args
2013-11-21 03:32:27ncoghlansetrecipients: + ncoghlan, gvanrossum, eric.smith, eric.araujo, eric.snow, dirn, Guido.van.Rossum, james, peyton
2013-11-21 03:32:27ncoghlanlinkissue19660 messages
2013-11-21 03:32:26ncoghlancreate