782
Comment:
|
3252
|
Deletions are marked like this. | Additions are marked like this. |
Line 4: | Line 4: |
in five five years from now... | in five five years from now... See http://www.python.org/peps/pep-3000.html for more information. = 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 regardless of the types of the numbers a and b, 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 }}} |
Line 15: | Line 40: |
'''Use new style classes in new code''' | '''Use new style classes in new code''' |
Line 28: | Line 53: |
= Let all exception classes inherit from Exception = From Python 3.0, all exceptions must be derived from Base''''''Exception, which will be the base class for Keyboard''''''Interrupt, System''''''Exit 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. = 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.
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 regardless of the types of the numbers a and b, 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.
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.