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

Sat May 6 15:22:10 CEST 2006

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.
 
