@@ -121,6 +121,8 @@ and work from there.
121121.. _Python 2.6 : http://www.python.org/2.6.x
122122.. _Python 2.5 : http://www.python.org/2.5.x
123123.. _Python 2.4 : http://www.python.org/2.4.x
124+ .. _Python 2.3 : http://www.python.org/2.3.x
125+ .. _Python 2.2 : http://www.python.org/2.2.x
124126
125127
126128.. _use_3to2 :
@@ -181,8 +183,8 @@ will be used for a rather long time. It also allows for use of the ``-3`` flag
181183to Python to help discover places in your code which 2to3 cannot handle but are
182184known to cause issues.
183185
184- Try to Support Python 2.6 and Newer Only
185- ----------------------------------------
186+ Try to Support ` Python 2.6 `_ and Newer Only
187+ -------------------------------------------
186188While not possible for all projects, if you can support `Python 2.6 `_ and newer
187189**only **, your life will be much easier. Various future statements, stdlib
188190additions, etc. exist only in Python 2.6 and later which greatly assist in
@@ -196,22 +198,6 @@ labeled as such). If you continue to support older versions of Python then you
196198at least need to watch out for situations that these solutions fix.
197199
198200
199- ``from __future__ import division ``
200- '''''''''''''''''''''''''''''''''''
201- While the exact same outcome can be had by using the ``-Qnew `` argument to
202- Python, using this future statement lifts the requirement that your users use
203- the flag to get the expected behavior of division in Python 3 (e.g., ``1/2 ==
204- 0.5; 1//2 == 0 ``).
205-
206-
207- ``from __future__ import absolute_imports ``
208- '''''''''''''''''''''''''''''''''''''''''''
209- Implicit relative imports (e.g., importing ``spam.bacon `` from within
210- ``spam.eggs `` with the statement ``import bacon ``) does not work in Python 3.
211- This future statement moves away from that and allows the use of explicit
212- relative imports (e.g., ``from . import bacon ``).
213-
214-
215201``from __future__ import print_function ``
216202'''''''''''''''''''''''''''''''''''''''''
217203This is a personal choice. 2to3 handles the translation from the print
@@ -251,13 +237,45 @@ Python 2, but ``b'a' + 'b'`` in Python 3 is a :exc:`TypeError`. A similar issue
251237also comes about when doing comparisons between bytes and strings.
252238
253239
240+ Supporting `Python 2.5 `_ and Newer Only
241+ ---------------------------------------
242+ If you are supporting `Python 2.5 `_ and newer there are still some features of
243+ Python that you can utilize.
244+
245+
246+ ``from __future__ import absolute_imports ``
247+ '''''''''''''''''''''''''''''''''''''''''''
248+ Implicit relative imports (e.g., importing ``spam.bacon `` from within
249+ ``spam.eggs `` with the statement ``import bacon ``) does not work in Python 3.
250+ This future statement moves away from that and allows the use of explicit
251+ relative imports (e.g., ``from . import bacon ``).
252+
253+ In `Python 2.5 `_ you must use
254+ the __future__ statement to get to use explicit relative imports and prevent
255+ implicit ones. In `Python 2.6 `_ explicit relative imports are available without
256+ the statement, but you still want the __future__ statement to prevent implicit
257+ relative imports. In `Python 2.7 `_ the __future__ statement is not needed. In
258+ other words, unless you are only supporting Python 2.7 or a version earlier
259+ than Python 2.5, use the __future__ statement.
260+
261+
262+
254263Handle Common "Gotchas"
255264-----------------------
256265There are a few things that just consistently come up as sticking points for
257266people which 2to3 cannot handle automatically or can easily be done in Python 2
258267to help modernize your code.
259268
260269
270+ ``from __future__ import division ``
271+ '''''''''''''''''''''''''''''''''''
272+ While the exact same outcome can be had by using the ``-Qnew `` argument to
273+ Python, using this future statement lifts the requirement that your users use
274+ the flag to get the expected behavior of division in Python 3
275+ (e.g., ``1/2 == 0.5; 1//2 == 0 ``).
276+
277+
278+
261279Specify when opening a file as binary
262280'''''''''''''''''''''''''''''''''''''
263281
@@ -288,8 +306,8 @@ possibilities:
288306
289307Subclass ``object ``
290308'''''''''''''''''''
291- New-style classes have been around since Python 2.2. You need to make sure you
292- are subclassing from ``object `` to avoid odd edge cases involving method
309+ New-style classes have been around since ` Python 2.2 `_ . You need to make sure
310+ you are subclassing from ``object `` to avoid odd edge cases involving method
293311resolution order, etc. This continues to be totally valid in Python 3 (although
294312unneeded as all classes implicitly inherit from ``object ``).
295313
@@ -336,7 +354,7 @@ This means you need to choose what an API is going to accept and create and
336354consistently stick to that API in both Python 2 and 3.
337355
338356
339- Bytes / unicode comparison
357+ Bytes / Unicode Comparison
340358**************************
341359
342360In Python 3, mixing bytes and unicode is forbidden in most situations; it
@@ -587,22 +605,25 @@ might make in writing cross-version code.
587605
588606Capturing the Currently Raised Exception
589607----------------------------------------
590- One change between Python 2 and 3 that will require changing how you code is
591- accessing the currently raised exception. In Python 2 the syntax to access the
592- current exception is::
608+ One change between Python 2 and 3 that will require changing how you code (if
609+ you support `Python 2.5 `_ and earlier) is
610+ accessing the currently raised exception. In Python 2.5 and earlier the syntax
611+ to access the current exception is::
593612
594613 try:
595614 raise Exception()
596615 except Exception, exc:
597616 # Current exception is 'exc'
598617 pass
599618
600- This syntax changed in Python 3 to::
619+ This syntax changed in Python 3 (and backported to `Python 2.6 `_ and later)
620+ to::
601621
602622 try:
603623 raise Exception()
604624 except Exception as exc:
605625 # Current exception is 'exc'
626+ # In Python 3, 'exc' is restricted to the block; Python 2.6 will "leak"
606627 pass
607628
608629Because of this syntax change you must change to capturing the current
@@ -622,7 +643,7 @@ likely don't need it.
622643
623644.. note ::
624645 In Python 3, the traceback is attached to the exception instance
625- through the ** __traceback__ ** attribute. If the instance is saved in
646+ through the `` __traceback__ `` attribute. If the instance is saved in
626647 a local variable that persists outside of the ``except `` block, the
627648 traceback will create a reference cycle with the current frame and its
628649 dictionary of local variables. This will delay reclaiming dead
0 commit comments