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