|
Size: 6305
Comment: converted to 1.6 markup
|
← Revision 29 as of 2019-10-19 22:14:19 ⇥
Size: 890
Comment: Remove Python 2 information, leaving a link to previous revision for accessibility
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| 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 five years from now. See [[http://www.python.org/peps/pep-3000.html|PEP 3000]] for more information. |
|
| Line 8: | Line 2: |
| The future of [[http://www.python.org/peps/pep-3000.html|Python 3000]] is now! As of January 2020 Python 2 will be in EOL (End Of Life) status and receive no further official support. After that date, there will be no further updates nor bugfixes. Since this end-of-life date has been planned for nearly a decade (the first end-of-life date was slated to happen in 2014, and was pushed back to 2020), and nearly all popular libraries have already ported their code, Python 2.x is well on its way out. | |
| Line 9: | Line 4: |
| * Keep in mind that only a little subset of existing Python 2.6 code is valid on Python 3.0. There is no guarantee that your code will run unmodified on Python 3.0, even if you follow the advices listed here. * See also the [[http://svn.python.org/view/sandbox/trunk/2to3/README?view=markup|2to3]] tool, that helps translating Python 2.6 to Python 3.0 code. Some changes listed here can be automatically translated with this tool. Also, check the changes that '''can't''' be translated by the tool. = Unit 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. '''Write unit tests for all new or refactored code.''' = True Division = Since the beginning, Python has yielded an integer result when two integers are divided (e.g., {{{3/2}}} yields {{{1}}}). While this is correct if we assume that dividing integers means integer division, 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|PEP 238]] for more information. '''Use true and floor division in new code.''' You can enable the new behaviour in Python 2.x as follows: {{{ >>> from __future__ import division # Enable the new behaviour >>> 3/2 1.5 >>> 3//2 1 }}} = Absolute imports = In Python 2.x, imports are implicitly relative. For instance, if you're editing the file {{{foo/__init__.py}}} and want to import the module at {{{foo/bar.py}}}, you could use {{{import bar}}}. In Python 3.0, this won't work, as all imports will be absolute by default. You should instead use {{{from foo import bar}}}; if you want to import a specific function or variable from {{{bar}}}, you can use relative imports, such as {{{from .bar import myfunction}}}). See [[http://www.python.org/dev/peps/pep-0328/|PEP 328]] for more information. '''Don't use implicitly relative imports in new code.''' = 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 Python 3.0, 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/|New-style Classes]] for more information. '''Use new style classes in new code.''' * Don't write {{{ class X: pass }}} * Instead, write {{{ class X(object): pass }}} = Exception class inheritance = Starting 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|PEP 352]] for more information. '''When defining new exception classes, always inherit (directly or indirectly) from {{{Exception}}}.''' {{{ class MyException(Exception): pass }}} = Arguments for raise statement = The {{{raise}}} statement currently accepts different syntaxes. This will be consolidated so that only one argument is allowed for {{{raise}}}: the exception object, created like any other object. Other syntaxes will be deprecated. '''Write the {{{raise}}} statement with the exception object as the only argument.''' * Don't write: {{{ raise MyException, "A nasty error" raise "Foo bar error: Invalid value" }}} * Instead, write: {{{ raise MyException("A nasty error") raise FooBarError("Invalid value") }}} = Comparison of incompatible types = 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 compare objects of different types with undefined comparison behaviour.''' = Deprecation of little-used alternative operators = One obvious way to test for inequality already exists: the {{{!=}}} operator. The rarely-used {{{<>}}} will go away. '''Use only {{{!=}}} for inequality comparison.''' The backtick syntax {{{`foo`}}}, which is equivalent to {{{repr(foo)}}}, will not exist in Python 3.0. Almost all code currently uses {{{repr(foo)}}} for this purpose, and the backtick syntax is little-known and less readable. '''Use only {{{repr(foo)}}} for the representation of an object.''' = New 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. '''Don't assign to names that will become keywords.''' = See more = Here are some more tips on writing Python code to be future proof with Python 3.0. * Collin Winter has 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 are gradually becoming enabled. (This example is from Python 2.3.) {{{ >>> import __future__ >>> for x in __future__.all_feature_names: ... print x, getattr(__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. |
[[https://wiki.python.org/moin/FutureProofPython?action=recall&rev=28|Previous page revisions]] have historical information that may be useful in porting or maintaining remaining Python 2 systems. If you need additional support in porting existing 2.x code to 3.x, please see the resources available for [[PortingPythonToPy3k|porting Python 2 code]]. |
The future of Python 3000 is now! As of January 2020 Python 2 will be in EOL (End Of Life) status and receive no further official support. After that date, there will be no further updates nor bugfixes. Since this end-of-life date has been planned for nearly a decade (the first end-of-life date was slated to happen in 2014, and was pushed back to 2020), and nearly all popular libraries have already ported their code, Python 2.x is well on its way out.
Previous page revisions have historical information that may be useful in porting or maintaining remaining Python 2 systems. If you need additional support in porting existing 2.x code to 3.x, please see the resources available for porting Python 2 code.