[Python-checkins] r45922 - peps/trunk/pep-0236.txt
george.yoshida
python-checkins at python.org
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.
More information about the Python-checkins
mailing list