mirror of
https://github.com/python/cpython.git
synced 2025-08-04 08:59:19 +00:00
Fixing broken links in doc, part 2: howto/
This commit is contained in:
parent
77fe77d4af
commit
9bdcb3bc8a
6 changed files with 44 additions and 51 deletions
|
@ -86,11 +86,11 @@ that you can make sure that you detect breakage during the transition. Tests als
|
|||
tend to be simpler than the code they are testing so it gives you an idea of how
|
||||
easy it can be to port code.
|
||||
|
||||
Drop support for older Python versions if possible. `Python 2.5`_
|
||||
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
|
||||
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. Choose the newest version
|
||||
Python 2.7 continues the trend in the stdlib. Choose the newest version
|
||||
of Python which you believe can be your minimum support version
|
||||
and work from there.
|
||||
|
||||
|
@ -144,19 +144,19 @@ for you.
|
|||
Support Python 2.7
|
||||
//////////////////
|
||||
|
||||
As a first step, make sure that your project is compatible with `Python 2.7`_.
|
||||
As a first step, make sure that your project is compatible with Python 2.7.
|
||||
This is just good to do as Python 2.7 is the last release of Python 2 and thus
|
||||
will be used for a rather long time. It also allows for use of the ``-3`` flag
|
||||
to Python to help discover places in your code where compatibility might be an
|
||||
issue (the ``-3`` flag is in Python 2.6 but Python 2.7 adds more warnings).
|
||||
|
||||
Try to Support `Python 2.6`_ and Newer Only
|
||||
///////////////////////////////////////////
|
||||
Try to Support Python 2.6 and Newer Only
|
||||
////////////////////////////////////////
|
||||
|
||||
While not possible for all projects, if you can support `Python 2.6`_ and newer
|
||||
While not possible for all projects, if you can support Python 2.6 and newer
|
||||
**only**, your life will be much easier. Various future statements, stdlib
|
||||
additions, etc. exist only in Python 2.6 and later which greatly assist in
|
||||
supporting Python 3. But if you project must keep support for `Python 2.5`_ then
|
||||
supporting Python 3. But if you project must keep support for Python 2.5 then
|
||||
it is still possible to simultaneously support Python 3.
|
||||
|
||||
Below are the benefits you gain if you only have to support Python 2.6 and
|
||||
|
@ -215,10 +215,10 @@ Discussed in more detail below, but you should use this future statement to
|
|||
prevent yourself from accidentally using implicit relative imports.
|
||||
|
||||
|
||||
Supporting `Python 2.5`_ and Newer Only
|
||||
///////////////////////////////////////
|
||||
Supporting Python 2.5 and Newer Only
|
||||
////////////////////////////////////
|
||||
|
||||
If you are supporting `Python 2.5`_ and newer there are still some features of
|
||||
If you are supporting Python 2.5 and newer there are still some features of
|
||||
Python that you can utilize.
|
||||
|
||||
|
||||
|
@ -230,11 +230,11 @@ Implicit relative imports (e.g., importing ``spam.bacon`` from within
|
|||
This future statement moves away from that and allows the use of explicit
|
||||
relative imports (e.g., ``from . import bacon``).
|
||||
|
||||
In `Python 2.5`_ you must use
|
||||
In Python 2.5 you must use
|
||||
the __future__ statement to get to use explicit relative imports and prevent
|
||||
implicit ones. In `Python 2.6`_ explicit relative imports are available without
|
||||
implicit ones. In Python 2.6 explicit relative imports are available without
|
||||
the statement, but you still want the __future__ statement to prevent implicit
|
||||
relative imports. In `Python 2.7`_ the __future__ statement is not needed. In
|
||||
relative imports. In Python 2.7 the __future__ statement is not needed. In
|
||||
other words, unless you are only supporting Python 2.7 or a version earlier
|
||||
than Python 2.5, use this __future__ statement.
|
||||
|
||||
|
@ -261,7 +261,7 @@ In Python 2.5 and earlier the syntax to access the current exception is::
|
|||
# Current exception is 'exc'.
|
||||
pass
|
||||
|
||||
This syntax changed in Python 3 (and backported to `Python 2.6`_ and later)
|
||||
This syntax changed in Python 3 (and backported to Python 2.6 and later)
|
||||
to::
|
||||
|
||||
try:
|
||||
|
@ -347,7 +347,7 @@ possibilities:
|
|||
Subclass ``object``
|
||||
'''''''''''''''''''
|
||||
|
||||
New-style classes have been around since `Python 2.2`_. You need to make sure
|
||||
New-style classes have been around since Python 2.2. You need to make sure
|
||||
you are subclassing from ``object`` to avoid odd edge cases involving method
|
||||
resolution order, etc. This continues to be totally valid in Python 3 (although
|
||||
unneeded as all classes implicitly inherit from ``object``).
|
||||
|
@ -610,12 +610,6 @@ please email the python-porting_ mailing list.
|
|||
.. _modernize: https://github.com/mitsuhiko/python-modernize
|
||||
.. _Porting to Python 3: http://python3porting.com/
|
||||
.. _PyPI: https://pypi.python.org/
|
||||
.. _Python 2.2: https://www.python.org/2.2.x
|
||||
.. _Python 2.5: https://www.python.org/2.5.x
|
||||
.. _Python 2.6: https://www.python.org/2.6.x
|
||||
.. _Python 2.7: https://www.python.org/2.7.x
|
||||
.. _Python 2.5: https://www.python.org/2.5.x
|
||||
.. _Python 3.3: https://www.python.org/3.3.x
|
||||
.. _Python 3 Packages: https://pypi.python.org/pypi?:action=browse&c=533&show=all
|
||||
.. _Python 3 Q & A: http://ncoghlan-devs-python-notes.readthedocs.org/en/latest/python3/questions_and_answers.html
|
||||
.. _python-porting: https://mail.python.org/mailman/listinfo/python-porting
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue