Differences between revisions 11 and 12
Revision 11 as of 2007-07-24 00:57:10
Size: 3873
Editor: 65
Comment:
Revision 12 as of 2007-07-24 01:30:30
Size: 4186
Editor: caramel
Comment: copy edit
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
Automated testing is generally better than debuging, and is your safety-net for any kind of refatoring, not only when migrating to a newer Python. Use PyUnit (unittest), DocTest or any alternative (see UnitTests) to help you. Automated testing is generally better than debugging, and is your safety-net for any kind of refactoring, not only when migrating to a newer Python. Use PyUnit (unittest), DocTest or any alternative (see UnitTests) to help you.
Line 19: Line 19:
a future Python version, so that a/b with yield a float as a a future Python version, so that a/b will yield a float as a
Line 40: Line 40:
work when the default swaps from old style to new style, there are work when the default switches from old style to new style, there are
Line 61: Line 61:
From Python 3.0, all exceptions must be derived from Base''''''Exception, Starting from Python 3.0, all exceptions must be derived from Base''''''Exception,
Line 64: Line 64:
Line 72: Line 71:
= Use parenthesis for Exception argument = = Use parentheses for Exception argument =
Line 84: Line 83:
= Don't compare uncomparable objects = = Don't compare incompatible objects =
Line 86: Line 85:
In the future, x < y and friends (>, <=, >=) will raise an exception instead
of an arbitrary result, if type(x) != type(y) unless the types explicitly
define the behaviour for these comparisions.
In the future, x < y and friends (>, <=, >=) will raise an exception instead of an arbitrary result, if type(x) != type(y) unless the types explicitly define the behaviour for these comparisions.
Line 92: Line 89:
It's enough with one inequality operator. Almost everybody uses !=. <> will go away. One obvious way to test for inequality already exists: the '!=' operator. The rarely-used '<>' will go away.
Line 96: Line 93:
The `backticks` for repr() will not exist in Python3.0 - Almost everybody use repr(foo), and many don't even know of `foo`. It is also harder to read. The `backticks` for repr() will not exist in Python 3.0. Almost all code currently uses repr(foo) for this purpose, and many don't even know of `foo`. It is also harder to read.
Line 98: Line 95:
= Don't assign to with, as, nonlocal, True and False = = Don't assign to names that will become keywords =
Line 100: Line 97:
They are becoming keywords. All of the names {{{with}}}, {{{as}}}, {{{nonlocal}}}, {{{True}}} and {{{False}}} are becoming keywords. Code that attempts to assign to those names will generate an exception in Python 3.0.
Line 104: Line 101:
Collin Winter have some tips in:
[http://oakwinter.com/code/porting-setuptools-to-py3k/]
Here are some more tips on writing Python code to be future proof with Python 3.0.

 *
Collin Winter have some tips in: [http://oakwinter.com/code/porting-setuptools-to-py3k/]
Line 108: Line 106:
Line 111: Line 110:
Line 120: Line 120:
The second tuple (e.g. (3, 0, 0, 'alpha', 0) for division) shows when a new
feature will become the default.

The second tuple (e.g. (3, 0, 0, 'alpha', 0) for division) shows when a new feature will become the default.

Python is a mature language, but it hasn't stopped evolving, and there are some issues to consider when coding Python, if you want your code to work with the latest version of Python in five five years from now... See http://www.python.org/peps/pep-3000.html for more information.

Write Tests

Automated testing is generally better than debugging, and is your safety-net for any kind of refactoring, not only when migrating to a newer Python. Use PyUnit (unittest), DocTest or any alternative (see UnitTests) to help you.

True Division

Since the beginning, Python has yielded an integer result when two integers are divided, e.g. 3/2 => 1. While correct if we assume that dividing integers means integer division (the remainder is accessible through the modulo operator %) it's not always obvious to beginners. This behaviour will change in a future Python version, so that a/b will yield a float as a result even if both a and b are integers, and a new floor division operator // will perform integer division. See See http://www.python.org/peps/pep-0238.html

  • Use true and floor division in new code

from __future__ import division # Enable the new behaviour

f = 3/2 # 1.5

i = 3//2 # 1

New style classes

Currently, there are two kinds of classes in Python. The 'classic' or old style classes, and the new style classes. Old style classes will go away in some future version, and while most code will still work when the default switches from old style to new style, there are some differences in semantics, and the new style classes have some extra features. See http://www.python.org/doc/newstyle.html

  • Use new style classes in new code

Don't write

class X:
    pass

Write

class X(object):
    pass

Let all exception classes inherit from Exception

Starting from Python 3.0, all exceptions must be derived from BaseException, which will be the base class for KeyboardInterrupt, SystemExit and Exception from Python 2.5. See http://www.python.org/peps/pep-0352.html

  • When defining new exception classes, always inherit (directly or indirectly) from Exception

class MyException(Exception): pass

Use parentheses for Exception argument

The syntax

raise MyException "A nasty error"

will be deprecated. Use

raise MyException("A nasty error")

instead.

Don't compare incompatible objects

In the future, x < y and friends (>, <=, >=) will raise an exception instead of an arbitrary result, if type(x) != type(y) unless the types explicitly define the behaviour for these comparisions.

Don't use <>

One obvious way to test for inequality already exists: the '!=' operator. The rarely-used '<>' will go away.

Don't use `` (backticks)

The backticks for repr() will not exist in Python 3.0. Almost all code currently uses repr(foo) for this purpose, and many don't even know of foo. It is also harder to read.

Don't assign to names that will become keywords

All of the names with, as, nonlocal, True and False are becoming keywords. Code that attempts to assign to those names will generate an exception in Python 3.0.

See more

Here are some more tips on writing Python code to be future proof with Python 3.0.

More changes in the future?

The following little code might be useful to run when you upgrade to a new Python version. It shows how some new features in Python is getting gradually enabled. (This example is from Python 2.3.)

>>> import __future__
>>> for x in __future__.all_feature_names:
...     print x, eval('__future__.'+x)
... 
nested_scopes _Feature((2, 1, 0, 'beta', 1), (2, 2, 0, 'alpha', 0), 16)
generators _Feature((2, 2, 0, 'alpha', 1), (2, 3, 0, 'final', 0), 4096)
division _Feature((2, 2, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 8192)

The second tuple (e.g. (3, 0, 0, 'alpha', 0) for division) shows when a new feature will become the default.

FutureProofPython (last edited 2019-10-19 22:14:19 by FrancesHocutt)

Unable to edit the page? See the FrontPage for instructions.