|
Size: 11334
Comment: Numpy 1.5 supports Python 3
|
Size: 927
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: |
| #acl Known:read,write,revert All:read |
|
| Line 5: | Line 3: |
| == What are the differences? == | You should use Python 3 going forward. As of January 2020 [[https://www.python.org/dev/peps/pep-0373/|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 [[https://python3statement.org/|have already ported their code]], Python 2.x is well on its way to obsolescence. As such, we can only recommend learning and teaching Python 3. |
| Line 7: | Line 5: |
| ''Short version: Python 2.x is the status quo, Python 3.x is the shiny new thing.'' | |
| Line 9: | Line 6: |
| At the time of writing (July 4, 2010), the final 2.7 release is out, 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 and continued development, with 3.1 already available and 3.2 due for release around the turn of the year. 3.x is the newest branch of Python and the intended future of the language. 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. This allowed several aspects of the core language (such as print and exec being statements, integers using floor division) to be adjusted to be easier for newcomers to learn and to be more consistent with the rest of the language. It also allowed later language features (such as iterators) to be applied to older language features (such as the `range` builtin which returns a list in 2.x, but an iterator in 3.x). The [[http://docs.python.org/release/3.1.2/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. 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 a lot of that software doesn't work on 3.x yet. == So 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's a few downsides, such as comparatively limited library support and the fact that current Linux distributions and Macs are still shipping with 2.x by 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 a lot of people reading this may only be developing something for themselves or an environment they control) and you're writing things where lack of third party software isn't a major impediment (or where you know the packages you need already support Python 3), Python 3.x is an excellent choice. Also, quite a few distributions have Python 3.x available already for end-users, even if none of them are using it as the default interpreter at the moment. 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. Popular modules that don't yet support Python 3 include Twisted (for networking and a bunch of other stuff), gevent (like Twisted but different), Django and Pylons (for building websites), PyGTK and PySide (for making GUIs), py2exe (for packaging your application for Windows users), PIL (for processing images)... Most of these libraries 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.) Of course, many packages have already been ported to 3.x. For example, people who want GUI functionality could use PyQt or Tkinter (shipped with the standard library) instead of PyGTK. And for number crunching, numpy supports Python 3 since [[http://projects.scipy.org/numpy/browser/trunk/doc/release/1.5.0-notes.rst|version 1.5]]. 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: again, this is a work in progress and this wiki page might be outdated. One issue with choosing Python 3 is that a lot of documentation (including examples) on the web and in reference books will be for Python 2. This can require some adjustment to make things work with Python 3 instead. Similarly, for those inclined to seek help via IRC, the #python regulars are typically seasoned developers who rely on legacy software, most of which hasn't been ported yet (Twisted and Zope come to mind, as well as the other examples given above). As a result, they might not be able to help with Python 3.x issues or issues pertaining to libraries that have been ported to 3.x as well as they could with otherwise comparable 2.x issues. This counts for many sources of help outside of #python as well for largely the same reason. Of course, this situation is continuously improving, and some problems aren't as 3.x-specific as you might think, so it might be worthwhile to give #python or alternative sources a help a shot anyway. That said, there are still significant sources of help, such as comp.lang.python, which do have a lot of 3.x users who may be able to help you with any problems. == But wouldn't I want to avoid 2.x? It's an old language with a bunch of mistakes, and it took a major version to get 'em out. == Well, not really. The good news is that you don't have to drop all of the 3.x goodness because you're using 2.x. A lot of the good ideas in 3.0 were backported to 2.6, and even more of the good ideas from 3.0, 3.1 and the upcoming 3.2 will be available in 2.7. The number of things that you really can't do in 2.x but can in 3.x is pretty small: it's just not always as elegant as it is in 3.x. A non-exhaustive list of features which are only available in 3.x releases and most likely won't be backported to the 2.x series: * function annotations * syntax for keyword-only arguments * extended tuple unpacking * non-local variable declarations For more details on the backported features, see [[http://docs.python.org/release/2.6.4/whatsnew/2.6.html|What's New in Python 2.6]] and [[http://docs.python.org/dev/whatsnew/2.7.html|What's New in Python 2.7]]. Well written 2.x code will actually be a lot like 3.x code. That can mean a lot of things, including using new-style classes, not using ancient deprecated arcane incantations of print, using lazy iterators where available... A practical example: good 2.x code will typically use xrange instead of range; xrange behaves just like 3.x' range (although range is even better in Python 3, since it can handle values larger than sys.maxint). 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 generally considered to be a good thing; it just 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? == Well, 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. Oftentimes 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 [[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!). 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. 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 which 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. == Other resources that may help make the choice between Python 2 and Python 3 == * Advice from the #python crew (the original inspiration for the contents of this page): http://python-commandments.org/python3.html * Nick Efford has some specific comments in relation to teaching programming with Python 3: http://www.comp.leeds.ac.uk/nde/papers/teachpy3.html * Mark Pilgrim has written a Python 3 focused version of Dive Into Python: http://diveintopython3.org/whats-new.html * "What an IronPython user should know about Python 3": http://www.itworld.com/development/104506/python-3-and-ironpython * !PyConIreland 2010 included a talk by Paul Barry entitled "Head First into Python 3" and is available here: http://vimeo.com/groups/pyconireland/videos/14354395 |
= Historical information = For historical information that may be useful in porting or maintaining remaining Python 2 systems, please see [[https://wiki.python.org/moin/Python2orPython3?action=recall&rev=96|previous page revisions]]. |
Should I use Python 2 or Python 3 for my development activity?
You should use Python 3 going forward. 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 to obsolescence. As such, we can only recommend learning and teaching Python 3.
Historical information
For historical information that may be useful in porting or maintaining remaining Python 2 systems, please see previous page revisions.