iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Minor polishing of words

This commit is contained in:
Andrew M. Kuchling 2004-09-01 15:44:33 +00:00
parent b13a4cc305
commit 6dd0e5c76f
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
pep-0318.txt
View File

@ -37,7 +37,7 @@ Motivation
==========
The current method of applying a transformation to a function or method
places the actual translation after the function body. For large
places the actual transformation after the function body. For large
functions this separates a key component of the function's behavior from
the definition of the rest of the function's external interface. For
example::
@ -84,7 +84,7 @@ wonder why it's been so difficult to arrive at a consensus. Discussions
have raged off-and-on at times in both comp.lang.python and the
python-dev mailing list about how best to implement function decorators.
There is no one clear reason why this should be so, but a few problems
seem to be most problematic.
seem to be most divisive.
* Disagreement about where the "declaration of intent" belongs.
Almost everyone agrees that decorating/transforming a function at the
@ -293,11 +293,11 @@ syntax used in 2.4a2::
There have been a number of objections raised to this location -- the
primary one is that it's the first real Python case where a line of code
has a result on a following line. The syntax available for in 2.4a3
has an effect on a following line. The syntax available in 2.4a3
requires one decorator per line (in a2, multiple decorators could be
specified on the same line).
People also complained that the syntax got unworldly quickly when
People also complained that the syntax quickly got unwieldy when
multiple decorators were used. The point was made, though, that the
chances of a large number of decorators being used on a single function
were small and thus this was not a large worry.
@ -306,9 +306,9 @@ Some of the advantages of this form are that the decorators live outside
the method body -- they are obviously executed at the time the function
is defined.
Another advantage is that being prefix to the function definition fit
Another advantage is that a prefix to the function definition fits
the idea of knowing about a change to the semantics of the code before
the code itself, thus knowing how to interpret the code's semantics
the code itself, thus you know how to interpret the code's semantics
properly without having to go back and change your initial perceptions
if the syntax did not come before the function definition.
@ -365,7 +365,7 @@ apply to the previous form) as:
.. _summarized the arguments:
http://mail.python.org/pipermail/python-dev/2004-August/047112.html
The next form is that the decorator syntax go inside the method body at
The next form is that the decorator syntax goes inside the method body at
the start, in the same place that docstrings currently live:
def foo(arg1,arg2):
@ -556,7 +556,7 @@ to Python decorators. The fact that @ was previously unused as a token
in Python also means it's clear there is no possibility of such code
being parsed by an earlier version of Python, leading to possibly subtle
semantic bugs. It also means that ambiguity of what is a decorator
and what isn't is removed. of That said, @ is still a fairly arbitrary
and what isn't is removed. That said, @ is still a fairly arbitrary
choice. Some have suggested using | instead.
For syntax options which use a list-like syntax (no matter where it