update from Kevin Smith
This commit is contained in:
parent
c0529bfcca
commit
079c5cca04
69
pep-0318.txt
69
pep-0318.txt
|
@ -8,7 +8,7 @@ Type: Standards Track
|
|||
Content-Type: text/plain
|
||||
Created: 05-Jun-2003
|
||||
Python-Version: 2.4
|
||||
Post-History: 09-Jun-2003, 10-Jun-2003
|
||||
Post-History: 09-Jun-2003, 10-Jun-2003, 27-Feb-2004
|
||||
|
||||
|
||||
Abstract
|
||||
|
@ -95,10 +95,50 @@ Proposal
|
|||
'def' NAME '(' PARAMETERS ')' ['as' DECORATORS] ':'
|
||||
|
||||
where DECORATORS is a comma-separated list of expressions,
|
||||
or a tuple.
|
||||
or a tuple. Using the latter form, the last example above
|
||||
would look like:
|
||||
|
||||
Other syntaxes have been proposed in comp.lang.python. The
|
||||
most common are demonstrated below.
|
||||
def foo(self) as (synchronized(lock), classmethod):
|
||||
perform method operation
|
||||
|
||||
This form make is possible for the list of decorators to
|
||||
span multiple lines without using the line continuation operator.
|
||||
|
||||
Alternate Syntaxes
|
||||
|
||||
Other syntaxes have been proposed in comp.lang.python and
|
||||
python-dev. Unfortunately, no one syntax has come out as a clear
|
||||
winner in the lengthy discussions. The most common suggestions
|
||||
are demonstrated below. The proposed syntax is also included
|
||||
for easy comparison.
|
||||
|
||||
Proposed Syntax
|
||||
|
||||
def foo(self) as synchronized(lock), classmethod:
|
||||
perform method operation
|
||||
|
||||
def foo(self) as (synchronized(lock), classmethod):
|
||||
perform method operation
|
||||
|
||||
Prefix Forms
|
||||
|
||||
def [synchronized(lock), classmethod] foo(self):
|
||||
perform method operation
|
||||
|
||||
def synchronized(lock), classmethod foo(self):
|
||||
perform method operation
|
||||
|
||||
# Same as above, but only identifiers are allowed
|
||||
sync = synchronized(lock)
|
||||
def sync, classmethod foo(self):
|
||||
perform method operation
|
||||
|
||||
# Java-like
|
||||
sync = synchronized(lock)
|
||||
def @sync @classmethod foo(self):
|
||||
perform method operation
|
||||
|
||||
Postfix Forms
|
||||
|
||||
def foo(self) [synchronized(lock), classmethod]:
|
||||
perform method operation
|
||||
|
@ -109,12 +149,13 @@ Proposal
|
|||
def foo(self) {'pre': synchronized(lock), 'classmethod': True}:
|
||||
perform method operation
|
||||
|
||||
These three forms use syntax that just seems arbitrary and which
|
||||
does not help the user to comprehend the meaning of it. In
|
||||
addition, since the order in which the decorators are applied
|
||||
may matter, the third, dictionary-style, syntax must be
|
||||
eliminated.
|
||||
|
||||
I'm not as fond of the forms that use '[ ]' since code like
|
||||
'foo()[a]' looks as if you are getting the item 'a' from 'foo()'.
|
||||
Although, this isn't as much of an issue when using '[ ]' in
|
||||
a prefix form. The Java-like syntax adds new syntax that is
|
||||
very arbitrary and is almost Perl-ish. In addition, since the
|
||||
order in which the decorators are applied may matter, the last,
|
||||
dictionary-style, syntax must be eliminated.
|
||||
|
||||
Implementation Issues
|
||||
|
||||
|
@ -151,6 +192,14 @@ Implementation Issues
|
|||
In either case, the modified function is bound to the function
|
||||
name when the 'def' statement is executed.
|
||||
|
||||
Open Issues
|
||||
|
||||
It is not clear at the moment if it is even possible to have
|
||||
multiple decorators for a function. If decorators are required
|
||||
to take a function/method and return a descriptor, it might
|
||||
not even be possible to wrap multiple decorators. This should
|
||||
be explored since the best syntax for multiple decorators
|
||||
may not be the same as the best syntax for a single decorator.
|
||||
|
||||
Current Implementations
|
||||
|
||||
|
|
Loading…
Reference in New Issue