[Python-checkins] r88362 - python/branches/py3k/Doc/howto/pyporting.rst

eli.bendersky python-checkins at python.org
Mon Feb 7 05:19:57 CET 2011


Author: eli.bendersky
Date: Mon Feb  7 05:19:57 2011
New Revision: 88362

Log:
Fix some typos and grammar

[commit during RC with Brett's approval]




Modified:
   python/branches/py3k/Doc/howto/pyporting.rst

Modified: python/branches/py3k/Doc/howto/pyporting.rst
==============================================================================
--- python/branches/py3k/Doc/howto/pyporting.rst	(original)
+++ python/branches/py3k/Doc/howto/pyporting.rst	Mon Feb  7 05:19:57 2011
@@ -22,7 +22,7 @@
 ===================
 When a project makes the decision that it's time to support both Python 2 & 3,
 a decision needs to be made as to how to go about accomplishing that goal.
-Which strategy goes with will depend on how large the project's existing
+The chosen strategy will depend on how large the project's existing
 codebase is and how much divergence you want from your Python 2 codebase from
 your Python 3 one (e.g., starting a new version with Python 3).
 
@@ -32,8 +32,8 @@
 
 If your project has a pre-existing Python 2 codebase and you would like Python
 3 support to start off a new branch or version of your project, then you will
-most likely want to :ref:`port using 2to3 <use_2to3>`. This will allow you port
-your Python 2 code to Python 3 in a semi-automated fashion and begin to
+most likely want to :ref:`port using 2to3 <use_2to3>`. This will allow you to
+port your Python 2 code to Python 3 in a semi-automated fashion and begin to
 maintain it separately from your Python 2 code. This approach can also work if
 your codebase is small and/or simple enough for the translation to occur
 quickly.
@@ -103,13 +103,12 @@
 approach more than another doesn't mean that some advice doesn't apply to other
 strategies.
 
-Five, drop support for older Python versions if possible. While not a
-requirement, `Python 2.5`_) introduced a lot of useful syntax and libraries
-which have become idiomatic in Python 3. `Python 2.6`_ introduced future
-statements which makes compatibility much easier if you are going from Python 2
-to 3.
+Five, drop support for older Python versions if possible. `Python 2.5`_
+introduced a lot of useful syntax and libraries which have become idiomatic
+in Python 3. `Python 2.6`_ introduced future statements which makes
+compatibility much easier if you are going from Python 2 to 3.
 `Python 2.7`_ continues the trend in the stdlib. So choose the newest version
-of Python for which you believe you believe can be your minimum support version
+of Python which you believe can be your minimum support version
 and work from there.
 
 


More information about the Python-checkins mailing list