A decorator syntax not yet mentioned (I think!)

Paul McGuire ptmcg at austin.rr._bogus_.com
Thu Aug 12 06:24:46 EDT 2004


"Michael Sparks" <michaels at rd.bbc.co.uk> wrote in message
news:cffbbu$amv$1 at nntp0.reith.bbc.co.uk...
> Peter Hansen wrote:
> > Carl Banks wrote:
> >> One thing that's different is that, in all those cases, the second
> >> block has a keyword that can't appear alone.  You can't have an
> >> except without a try, or an else without an if, but you could have a
> >> def without a decorate.
> ...
> > is this an argument based on presumed difficulties in
> > implementing the idea?
>
> Looking at the wiki it states (as negative points):
>    1 New keyword
>    2 Overkill for the simple case like classmethod
>    3 Many people felt it was wrong use of an identation suite.
>    4 Has the same problem as 5.A, in that the decorate block implicitly
>      affects the following def. This does not occur elsewhere in Python.
>    5 Technical problems with the current grammar parser if a suite
>      *starts* with an optional part. (Ending with an optional part, such
>      as "else:" is OK, but starting with one is not.)
>    6 No implementation currently exists.
>
<snip>
> Item 6 is always the case for any new feature, so I doubt that's the
> real problem - the real problem here strikes me as item 5.
>
> I do wonder how difficult it would be to add though...
>

Looking at the code, it appears that this is how the current '@' syntax is
defined, that a funcdef is optionally preceded by a 'decorators' group,
consisting of one or more 'decorator' (looking at both Grammar/Grammar and
compile.c).

So I think this 'technical problem' is just conjecture.  (Should check with
Anthony Baxter to confirm.)

-- Paul







More information about the Python-list mailing list