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

Typo fixes

This commit is contained in:
George Yoshida 2006-05-06 13:22:09 +00:00
parent d487898001
commit 413017574b
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
pep-0236.txt
View File

@ -164,7 +164,7 @@ Standard Module __future__.py
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 @@ Questions and Answers
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 @@ Questions and Answers
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.