diff --git a/pep-0318.txt b/pep-0318.txt
index 136ea16a0..f9867dc3f 100644
--- a/pep-0318.txt
+++ b/pep-0318.txt
@@ -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