[Python-checkins] r45922 - peps/trunk/pep-0236.txt

[george.yoshida]

Author: george.yoshida
Date: Sat May  6 15:22:09 2006
New Revision: 45922

Modified:
   peps/trunk/pep-0236.txt
Log:
Typo fixes


Modified: peps/trunk/pep-0236.txt
==============================================================================
--- peps/trunk/pep-0236.txt	(original)
+++ peps/trunk/pep-0236.txt	Sat May  6 15:22:09 2006
@@ -164,7 +164,7 @@
        documentation, and can be inspected programatically via importing
        __future__ and examining its contents.
 
-    Each statment in __future__.py is of the form:
+    Each statement in __future__.py is of the form:
 
         FeatureName = "_Feature(" OptionalRelease "," MandatoryRelease ")"
 
@@ -284,14 +284,14 @@
     A:  Outside the scope of this PEP.  Seems unlikely to the author,
         though.  Write a PEP if you want to pursue it.
 
-    Q:  What about incompatibilites due to changes in the Python virtual
+    Q:  What about incompatibilities due to changes in the Python virtual
         machine?
 
     A:  Outside the scope of this PEP, although PEP 5 [1] suggests a grace
         period there too, and the future_statement may also have a role to
         play there.
 
-    Q:  What about incompatibilites due to changes in Python's C API?
+    Q:  What about incompatibilities due to changes in Python's C API?
 
     A:  Outside the scope of this PEP.
 
@@ -332,7 +332,7 @@
         introduce a new keyword, we can't introduce an entirely new
         statement.  But if we introduce a new keyword, that in itself
         would break old code.  That would be too ironic to bear.  Yes,
-        overloading "import" does suck, but not as energeticallly as the
+        overloading "import" does suck, but not as energetically as the
         alternatives -- as is, future_statements are 100% backward
         compatible.