Differences between revisions 5 and 10 (spanning 5 versions)
Revision 5 as of 2006-02-20 23:09:49
Size: 2566
Editor: 60
Comment: spelling mistake Excption -> Exception in exception section
Revision 10 as of 2007-07-23 23:56:29
Size: 3872
Editor: 201-26-163-184
Comment: colin post
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:

= Write Tests =

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.
Line 16: Line 20:
result regardless of the types of the numbers a and b, and result even if both a and b are integers, and
Line 89: Line 93:

= Don't use `` (backticks) =

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.

= Don't assign to with, as, nonlocal, True and False =

They are becoming keywords.

= See more =

Colin Winter have some tips in:
[http://oakwinter.com/code/porting-setuptools-to-py3k/]

= 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.

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 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.

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 with 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 swaps 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

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 parenthesis for Exception argument

The syntax

raise MyException "A nasty error"

will be deprecated. Use

raise MyException("A nasty error")

instead.

Don't compare uncomparable 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 <>

It's enough with one inequality operator. Almost everybody uses !=. <> will go away.

Don't use `` (backticks)

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.

Don't assign to with, as, nonlocal, True and False

They are becoming keywords.

See more

Colin Winter have some tips in: [http://oakwinter.com/code/porting-setuptools-to-py3k/]

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.