Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit ce71ab2

Browse files
committed
Re-arrange and clarify some __future__ import statements.
The absolute_import statement got moved to a new Python 2.5 and Newer section as it was available since then. The division statement got moved to Common Gotchas since it has been around for so long that any modern Python program can use it.
1 parent e09d2f1 commit ce71ab2

1 file changed

Lines changed: 47 additions & 26 deletions

File tree

Doc/howto/pyporting.rst

Lines changed: 47 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -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
181183
to Python to help discover places in your code which 2to3 cannot handle but are
182184
known 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+
-------------------------------------------
186188
While 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
188190
additions, 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
196198
at 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
'''''''''''''''''''''''''''''''''''''''''
217203
This 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
251237
also 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+
254263
Handle Common "Gotchas"
255264
-----------------------
256265
There are a few things that just consistently come up as sticking points for
257266
people which 2to3 cannot handle automatically or can easily be done in Python 2
258267
to 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+
261279
Specify when opening a file as binary
262280
'''''''''''''''''''''''''''''''''''''
263281

@@ -288,8 +306,8 @@ possibilities:
288306

289307
Subclass ``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
293311
resolution order, etc. This continues to be totally valid in Python 3 (although
294312
unneeded 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
336354
consistently stick to that API in both Python 2 and 3.
337355

338356

339-
Bytes / unicode comparison
357+
Bytes / Unicode Comparison
340358
**************************
341359

342360
In Python 3, mixing bytes and unicode is forbidden in most situations; it
@@ -587,22 +605,25 @@ might make in writing cross-version code.
587605

588606
Capturing 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

608629
Because 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

Comments
 (0)