Differences between revisions 71 and 72
Revision 71 as of 2013-10-30 10:12:02
Size: 13638
Editor: LachlanDufty
Comment: Page text had been replaced with: "Hi, everybody! I'm Swedish male :D. I really like Grey's Anatomy!"
Revision 72 as of 2014-01-02 08:33:16
Size: 17510
Editor: NickCoghlan
Comment: Various updates, saving before starting the list of backports.
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
The final 2.x version 2.7 release came out in mid-2010, with a statement of extended support for this end-of-life release. The 2.x branch will see no new major releases after that. 3.x is under active development and has already seen over two years of stable releases, including version 3.3 in 2012. This means that all recent standard library improvements, for example, are only available in Python 3.x. The final 2.x version 2.7 release came out in mid-2010, with a statement of extended support for this end-of-life release. The 2.x branch will see no new major releases after that. 3.x is under active development and has already seen over four years of stable releases, including version 3.3 in 2012. The next release is the upcoming Python 3.4 in early 2014. This means that all recent standard library improvements, for example, are only available by default in Python 3.x.
Line 11: Line 11:
The [[http://docs.python.org/py3k/whatsnew/3.0.html|What's New in Python 3.0]] document provides a good overview of the major language changes and likely sources of incompatibility with existing Python 2.x code. The [[http://docs.python.org/py3k/whatsnew/3.0.html|What's New in Python 3.0]] document provides a good overview of the major language changes and likely sources of incompatibility with existing Python 2.x code. Nick Coghlan (one of the CPython core developers) has also created a [[http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html|relatively extensive FAQ]] regarding the transition.
Line 20: Line 20:
In particular, instructors introducing Python to new programmers may want to consider teaching Python 3 first and then introducing the differences in Python 2 afterwards (if necessary), since Python 3 [[http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#why-is-python-3-considered-a-better-language-to-teach-beginning-programmers|eliminates many quirks]] that can unnecessarily trip up beginning programmers trying to learn Python 2.
Line 25: Line 27:
Popular modules that don't yet support Python 3 include [[http://twistedmatrix.com/trac/wiki|Twisted]] (for networking and other applications), [[http://code.google.com/p/gevent/|gevent]] (like Twisted, but different). Especially popular modules that don't yet support Python 3 include [[http://twistedmatrix.com/trac/wiki|Twisted]] (for networking and other applications), [[http://code.google.com/p/gevent/|gevent]] (a network library like Twisted, but using
micro-threads rather than an explicitly asynchronous style
).
Line 35: Line 38:
 * PIL (an image processing module) was superseeded by its fork Pillow, which supports Python3.  * PIL (an image processing module) was superseded by its fork Pillow, which supports Python3.
Line 39: Line 42:
If you want to use Python 3.x, but you're afraid to because of a dependency, it's probably worthwhile doing some research first. This is a work in progress and this wiki page might be outdated. If you want to use Python 3.x, but you're afraid to because of a dependency, it's probably worthwhile doing some research first. This is a work in progress and this wiki page might be outdated. Furthermore, with the large common subset supported by both Python 2.6+ and Python 3.3+, much modern Python code should run largely unmodified on Python 3, especially code written to interoperate with web and GUI frameworks that force applications to correctly distinguish binary data and text (some assistance from the [[https://pypi.python.org/pypi/six|six compatibility module]] may be needed to handle name changes.
Line 41: Line 44:
Even if the [[http://docs.python.org/py3k/|official python documentation]] and the [[http://docs.python.org/py3k/tutorial/|tutorial]] have been updated for Python 3, there is still a lot of documentation (including examples) on the Web and in reference books that use Python 2, although more are being updated all the time. This can require some adjustment to make things work with Python 3 instead. Even though the [[http://docs.python.org|official python documentation]] and the [[http://docs.python.org/3/tutorial/|tutorial]] have been updated for Python 3, there is still a lot of documentation (including examples) on the Web and in reference books that use Python 2, although more are being updated all the time. This can require some adjustment to make things work with Python 3 instead.
Line 58: Line 61:
Also, language evolution is not limited to core syntactic or semantic changes. It also regards the standard library, where many improvements are done in 3.x that will not be backported to Python 2. See [[http://docs.python.org/3/whatsnew|What's New in Python 3]], for example. Also, language evolution is not limited to core syntactic or semantic changes. It also regards the standard library, where many improvements are done in 3.x that will not be backported directly to Python 2. See [[http://docs.python.org/3/whatsnew|What's New in Python 3]], for example. However, a number of the standard library improvements are also available through PyPI.
Line 73: Line 76:
How you're supposed to do porting is explained in [[http://www.python.org/dev/peps/pep-3000/#id9|PEP 3000]]. The basic idea is to take the 2.x version of the library and use the automated 2to3 converter to create a Python 3 compatible version and check that all the unit tests still pass. If tests fail, modify the original 2.x sources and try again. This approach makes it feasible to support 2.x and 3.x in parallel from a single 2.x code base. This is much easier than trying to maintain separate 2.x and 3.x branches in parallel (just ask the core Python developers about that one - they've been stuck with doing that for a couple of years now!). How you're supposed to do porting is explained in this [[http://docs.python.org/3/howto/pyporting.html|Python 2 porting guide]]. The basic idea is to take the 2.x version of the library and check that all the unit tests still pass without warning when using the -3 command line switch in Python 2. If tests fail or emit warnings, modify the sources and try again (this may require dropping compatibility with older Python versions). Once the code runs without warnings when using the -3 switch, then try running it with Python 3. The best possible case is when this "just works" - code written using modern Python 2 idioms is source compatible with Python 3, so it's possible that the "port" may be complete at this point.
Line 75: Line 78:
The porting situation is more complicated if there are C extension modules involved, but even then it is still likely to be easier than inventing your own equivalent package. If the tests still fail under Python 3, then the standard library's 2to3 utility can often automatically create a version that will run under Python 3. Alternatively, Armin Ronacher's [[https://pypi.python.org/pypi/modernize|python-modernize]] utility instead targets the common subset of Python 2.6+ and either 3.2+ or 3.3+ (depending on the command line options used). (If using the latter, it's important to check the tests still pass under Python 2 as well!)

Either approach makes it feasible to support 2.x and 3.x in parallel from a single 2.x code base. This is much easier than trying to maintain separate 2.x and 3.x branches in parallel (just ask the core Python developers about that one - they've been stuck with doing that for a few years now!).

If the tests still fail after automated conversion or modernisation, the code may be affected by a semantic change between Python 2 and 3 that the converters can't handle automatically and that isn't detected by the -3 switch. Such issues should be rare, but may still exist - if one is encountered, it's worth filing a bug against CPython requesting a new -3 warning.

The porting situation is potentially more complicated if there are C extension modules involved and the project isn't using a wrapper generator like Cython, cffi or SWIG that automatically handles the differences between Python 2 and 3, but even then it is still likely to be easier than inventing your own equivalent package. The [[http://docs.python.org/3/howto/cporting.html|extension porting guide]] covers some of the key differences.
Line 84: Line 93:
[[http://packages.python.org/six/|six]] is another tool.
== Supporting Python 2 and Python 3 in a common code base ==

The common subset of Python 2.6+ and Python 3.3+ is quite large - the restoration of u prefix support for unicode literals in Python 3.3 means that semantically correct Python 2.6+ code can be made source compatible with Python 3.3+ while still remaining largely idiomatic Python. The main difference is that some things will need to be imported from different places in order to handle the fact they have different names in Python 2 and Python 3.

Accordingly, the [[http://packages.python.org/six/|six compatibility package]] is a key utility for supporting Python 2 and Python 3 in a single code base.

Another key thing to identify for standard library modules is if there is a more up to date backport on PyPI that can be used in preference to the 2.x standard library version.
Line 98: Line 114:
 * Nick Coghlan has [[http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html|an FAQ]] cover many details of the rationale behind creating Python 3, the intended migration plan, and the current status of the transition

Should I use Python 2 or Python 3 for my development activity?

What are the differences?

Short version: Python 2.x is legacy, Python 3.x is the present and future of the language

The final 2.x version 2.7 release came out in mid-2010, with a statement of extended support for this end-of-life release. The 2.x branch will see no new major releases after that. 3.x is under active development and has already seen over four years of stable releases, including version 3.3 in 2012. The next release is the upcoming Python 3.4 in early 2014. This means that all recent standard library improvements, for example, are only available by default in Python 3.x.

Guido van Rossum (the original creator of the Python language) decided to clean up Python 2.x properly, with less regard for backwards compatibility than is the case for new releases in the 2.x range. The most drastic improvement is the better Unicode support (with all text strings being Unicode by default) as well as saner bytes/Unicode separation.

Besides, several aspects of the core language (such as print and exec being statements, integers using floor division) have been adjusted to be easier for newcomers to learn and to be more consistent with the rest of the language, and old cruft has been removed (for example, all classes are now new-style, "range()" returns a memory efficient iterable, not a list as in 2.x).

The What's New in Python 3.0 document provides a good overview of the major language changes and likely sources of incompatibility with existing Python 2.x code. Nick Coghlan (one of the CPython core developers) has also created a relatively extensive FAQ regarding the transition.

However, the broader Python ecosystem has amassed a significant amount of quality software over the years. The downside of breaking backwards compatibility in 3.x is that some of that software (especially in-house software in companies) still doesn't work on 3.x yet.

Which version should I use?

Which version you ought to use is mostly dependent on what you want to get done.

If you can do exactly what you want with Python 3.x, great! There are a few minor downsides, such as slightly worse library support1 and the fact that most current Linux distributions and Macs are still using 2.x as default, but as a language Python 3.x is definitely ready. As long as actually getting Python 3.x on your user's computers (which ought to be easy, since many people reading this may only be developing something for themselves or an environment they control) and you're writing things where you know none of the modules still not supporting Python 3.x are needed, it is an excellent choice. Also, most linux distributions have Python 3.x already installed, and all have it available for end-users. Some are phasing out Python 2 as preinstalled default.2

In particular, instructors introducing Python to new programmers may want to consider teaching Python 3 first and then introducing the differences in Python 2 afterwards (if necessary), since Python 3 eliminates many quirks that can unnecessarily trip up beginning programmers trying to learn Python 2.

However, there are some key issues that may require you to use Python 2 rather than Python 3.

  • Firstly, if you're deploying to an environment you don't control, that may impose a specific version, rather than allowing you a free selection from the available versions.
  • Secondly, if you want to use a specific third party package or utility that doesn't yet have a released version that is compatible with Python 3, and porting that package is a non-trivial task, you may choose to use Python 2 in order to retain access to that package.

Especially popular modules that don't yet support Python 3 include Twisted (for networking and other applications), gevent (a network library like Twisted, but using micro-threads rather than an explicitly asynchronous style).

Most libraries like these have people working on 3.x support and it's mostly a work in progress in various stages of completion. For some libraries, it's more of a priority than others: Twisted, for example, is mostly focused on production servers, where supporting older versions of Python is important, let alone supporting a new version that includes major changes to the language. (Twisted is a prime example of a major package where porting to 3.x is far from trivial.)

For creating GUI applications Python 3 already comes with Tkinter, and has been supported by PyQt almost from the day Python 3 was released; PySide added Python 3 support in 2011. GTK+ GUIs can be created with PyGObject which supports Python 3 and is the successor to PyGtk.

Many other major packages have been ported to Python 3 including:

  • numpy (for number crunching)

  • Django, Flask, CherryPy and Pyramid (for Web sites)

  • PIL (an image processing module) was superseded by its fork Pillow, which supports Python3.
  • cx_Freeze (for packaging applications with their dependencies)

  • py2exe (for packaging your application for Windows users)

If you want to use Python 3.x, but you're afraid to because of a dependency, it's probably worthwhile doing some research first. This is a work in progress and this wiki page might be outdated. Furthermore, with the large common subset supported by both Python 2.6+ and Python 3.3+, much modern Python code should run largely unmodified on Python 3, especially code written to interoperate with web and GUI frameworks that force applications to correctly distinguish binary data and text (some assistance from the six compatibility module may be needed to handle name changes.

Even though the official python documentation and the tutorial have been updated for Python 3, there is still a lot of documentation (including examples) on the Web and in reference books that use Python 2, although more are being updated all the time. This can require some adjustment to make things work with Python 3 instead.

It is worth noting that if you wish to use an alternative implementation of Python such as IronPython, Jython or PyPy (or one of the longer list of Python platform or compiler implementations), Python 3 support is still relatively rare. This may affect you if you are interested in choosing such an implementation for reasons of integration with other systems or for performance.

But wouldn't I want to avoid 2.x? It's an old language with many mistakes, and it took a major version to get them out.

Well, not entirely. Some of the less disruptive improvements in 3.0 and 3.1 have been backported to 2.6 and 2.7, respectively. For more details on the backported features, see What's New in Python 2.6 and What's New in Python 2.7.

A non-exhaustive list of features which are only available in 3.x releases and won't be backported to the 2.x series:

  • strings are Unicode by default
  • clean Unicode/bytes separation
  • exception chaining
  • function annotations
  • syntax for keyword-only arguments
  • extended tuple unpacking
  • non-local variable declarations

Also, language evolution is not limited to core syntactic or semantic changes. It also regards the standard library, where many improvements are done in 3.x that will not be backported directly to Python 2. See What's New in Python 3, for example. However, a number of the standard library improvements are also available through PyPI.

That said, well-written 2.x code can be a lot like 3.x code. That can mean many things, including using new-style classes, not using ancient deprecated arcane incantations of print, using lazy iterators where available, etc. A practical example: good 2.x code will typically use xrange instead of range; xrange was the starting point for the Python 3.x range implementation (although range is even better in Python 3, since it can handle values larger than sys.maxint). It should be noted that xrange() is not included in Python 3.

Above all, it is recommended that you focus on writing good code so that 2.x vs 3.x becomes less of an issue. That includes writing full unit test suites, and getting Unicode right. (Python 3.x is significantly less forgiving than 2.x about Unicode versus bytes issues: This is considered to be a good thing, though it makes porting some software packages fairly annoying.)

I want to use Python 3, but there's this tiny library I want to use that's Python 2.x only. Do I really have to revert to using Python 2 or give up on using that library?

Assuming you can't find an alternative package that already supports Python 3, you still have a few options to consider:

  • Port the library to 3.x. ("Porting" means that you make the library work on 3.x.)
  • If that turns out to be really hard, and all your other dependencies do exist in 2.x, consider starting off in 2.x. As has already been explained in other places, good 2.x code will typically make switching painless as soon as every dependency has been successfully ported.
  • Decide if the feature is really that important. Maybe you could drop it?

The ideal situation is that you try to port the library to 3.x. Often you'll find someone is already working on this. Even when that's not the case, existing project members will usually appreciate the help, especially as porting often finds bugs in the original software, improving the quality of both the original and the 3.x port. Porting isn't always easy, but it's usually easier than writing your own thing from scratch.

How you're supposed to do porting is explained in this Python 2 porting guide. The basic idea is to take the 2.x version of the library and check that all the unit tests still pass without warning when using the -3 command line switch in Python 2. If tests fail or emit warnings, modify the sources and try again (this may require dropping compatibility with older Python versions). Once the code runs without warnings when using the -3 switch, then try running it with Python 3. The best possible case is when this "just works" - code written using modern Python 2 idioms is source compatible with Python 3, so it's possible that the "port" may be complete at this point.

If the tests still fail under Python 3, then the standard library's 2to3 utility can often automatically create a version that will run under Python 3. Alternatively, Armin Ronacher's python-modernize utility instead targets the common subset of Python 2.6+ and either 3.2+ or 3.3+ (depending on the command line options used). (If using the latter, it's important to check the tests still pass under Python 2 as well!)

Either approach makes it feasible to support 2.x and 3.x in parallel from a single 2.x code base. This is much easier than trying to maintain separate 2.x and 3.x branches in parallel (just ask the core Python developers about that one - they've been stuck with doing that for a few years now!).

If the tests still fail after automated conversion or modernisation, the code may be affected by a semantic change between Python 2 and 3 that the converters can't handle automatically and that isn't detected by the -3 switch. Such issues should be rare, but may still exist - if one is encountered, it's worth filing a bug against CPython requesting a new -3 warning.

The porting situation is potentially more complicated if there are C extension modules involved and the project isn't using a wrapper generator like Cython, cffi or SWIG that automatically handles the differences between Python 2 and 3, but even then it is still likely to be easier than inventing your own equivalent package. The extension porting guide covers some of the key differences.

There are also some more in depth guides right here on the wiki: PortingPythonToPy3k, PortingExtensionModulesToPy3k

I decided to write something in 3.x but now someone wants to use it who only has 2.x. What do I do?

In addition to the 2to3 tool that allows 3.x code to be generated from 2.x source code, there's also the 3to2 tool, which aims to convert 3.x code back to 2.x code. In theory, this should work even better than going the other direction, since 3.x doesn't have as many nasty corner cases for the converter to handle (getting rid of as many of those as possible was one of the main reasons for breaking backward compatibility after all!). However, code which makes heavy use of 3.x only features (such as function annotations or extended tuple unpacking) is unlikely to be converted successfully.

It's probably also fair to say that 3to2 is the road less traveled compared to 2to3 at this stage, so you might come across a few rough edges here and there. However, if you want to write 3.x code, it's definitely an idea worth exploring.

Supporting Python 2 and Python 3 in a common code base

The common subset of Python 2.6+ and Python 3.3+ is quite large - the restoration of u prefix support for unicode literals in Python 3.3 means that semantically correct Python 2.6+ code can be made source compatible with Python 3.3+ while still remaining largely idiomatic Python. The main difference is that some things will need to be imported from different places in order to handle the fact they have different names in Python 2 and Python 3.

Accordingly, the six compatibility package is a key utility for supporting Python 2 and Python 3 in a single code base.

Another key thing to identify for standard library modules is if there is a more up to date backport on PyPI that can be used in preference to the 2.x standard library version.

Other resources that may help make the choice between Python 2 and Python 3

Footnotes

  1. Amongst still-maintained packages: https://python3wos.appspot.com (1)

  2. Arch Linux links python to python3, and Ubuntu and Fedora switch defaults: https://wiki.ubuntu.com/Python/3 https://fedoraproject.org/wiki/Changes/Python_3_as_Default (2)

Python2orPython3 (last edited 2020-06-17 20:07:07 by MatsWichmann)

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