Python 3.1 released(python.org)
python.org
Python 3.1 released
http://www.python.org/download/releases/3.1/
23 comments
Is anyone here actually using Python 3 or at least planning a migration? I am wondering when the fallover is finally going to happen if no one takes the initiative.
One of the Python GSoC projects this year is a Python 3to2 tool that lets you convert Python 3.0 code to work on 2.x. Once this is implemented, the major projects (like Django) can switch over to 3.0 without having to put work into 2.x branches, and that should provide critical mass for normal developers to switch over too.
Here's the proposal: http://socghop.appspot.com/student_project/show/google/gsoc2...
Here's the proposal: http://socghop.appspot.com/student_project/show/google/gsoc2...
It's a big waiting game; any projects that have dependencies on other python projects usually need to wait until their dependencies are ready first. Hopefully the number of projects that are ready will reach critical mass, and it'll kickstart a larger migration. It might take a while, though.
At least with GitHub et. al., it's a lot easier nowadays to maintain a fork of a dependency for Py3k compatibility (or to keep a 2.x branch, for that matter).
EDIT: The primary projects I use are Pylons and Eventlet. Pylons has a roadmap to migrate to 3.0; not sure about Eventlet.
At least with GitHub et. al., it's a lot easier nowadays to maintain a fork of a dependency for Py3k compatibility (or to keep a 2.x branch, for that matter).
EDIT: The primary projects I use are Pylons and Eventlet. Pylons has a roadmap to migrate to 3.0; not sure about Eventlet.
Take Django, one of the most successful Python projects. They were recently debating whether to drop Python 2.3 support or not. RHEL 4 shipped Python 2.3 and Redhat supports it until February 29, 2012. Se this thread for detailed reasoning: http://groups.google.com/group/django-developers/msg/0888b1c...
In other words, we won't see any major projects dropping 2.x support in the foreseeable future.
In other words, we won't see any major projects dropping 2.x support in the foreseeable future.
This is one big problem with Python libs and evolution of the versioning. The best default support you can get is 2.4 even at places like Joyent due to Redhat and RHEL and other package systems. It is unfortunate.
I was hoping stuff like Django, SQL Alchemy, Google AppEngine and even Unladen Swallow to focus more on Python 3 btu there is so much vested in older versions. If everyone could just get to 2.6 or 2.7 at least then new frameworks and old stuff can run for a while.
But python evolution is a bit held back by situations like this. That is one problem that Ruby, .NET etc dont' have and as a Pythonista for the last few years, this is concerning.
Google AppEngine may be adding python version support soon. There should be an easier way to have parallel python libs and switch between them per app.
Hopefully this is a focus soon.
I was hoping stuff like Django, SQL Alchemy, Google AppEngine and even Unladen Swallow to focus more on Python 3 btu there is so much vested in older versions. If everyone could just get to 2.6 or 2.7 at least then new frameworks and old stuff can run for a while.
But python evolution is a bit held back by situations like this. That is one problem that Ruby, .NET etc dont' have and as a Pythonista for the last few years, this is concerning.
Google AppEngine may be adding python version support soon. There should be an easier way to have parallel python libs and switch between them per app.
Hopefully this is a focus soon.
What you refer to as a "big problem" and "holding back" of the evolution, I don't see at all in the same perspective.
Its not imo an infrequent occurrence that software authors decide to do things so differently in a new version, that it fundamentally breaks compatibility with the old way of doing things.
Ie python 3 is something different from python 2; just like how in the C world a libXYZ.1.0 may have an entirely different api from a libXYZ.2.0, or how linux 2.6 differs from 2.4 for device driver writers etc; because the developers felt there was a compelling reason/opportunity to do things differently/better as the world moved forward.
In all cases, authors of other 3rd party software somehow dependent on the above (ie python, the hypothetical libXYZ etc) must then decide when/if they will transition to the new way of doing things.
And this in turn will have a knock-on effect on users of that 3rd party software, who in turn may suddenly have some further constraints imposed on them in terms of what they can and can't combine, what additional testing may be required etc.
That is just the price of progress; and frankly I don't see that anything else (Ruby, .NET) is somehow immune to this ever happening.
I build a lot of embedded systems that combine a variety of components, libraries etc, and there are forever dances around picking versions of things to get compatible dependencies, over the whole spectrum of technologies.
There are also always degrees of freedom, ie sometimes you just have to use both the old and new versions to satisfy dependencies for other components, run things as separate executables and then stitch those together via an ipc mechanism.
I don't think its realistic to think anyone's base technology might not ever change incompatibly; and so even though it might bring more work for a while, I don't see this change in python as anything so different from what we deal with anyway elsewhere, that it would merit me to consider for a moment replacing python with something else, either in the embedded environment or elsewhere.
In fact I applaud the python developers for their courage to be able to walk away from old paradigms and cut old cruft.
Maybe in looking at something like Ruby, right now you might feel a pythonista to be at a disadvantage to a rubyist if the latter is perceived as working with a more "stable" (unchanging) platform at this particular moment, and who's to say you're not justified in feeling so; but to my way of thinking it seems virtually assured that at some future point, Ruby will also undergo the same type of thing.
(Or, as tends to happen to those technologies where developers cannot find the courage to walk away from the old, things stagnate and love withers away).
Thus, I do not see this change holding back the evolution of python at all.
In fact I would argue evolution of a technology is held back precisely when the developers thereof cannot bring themselves to do the necessary to replace the old by the new, for fear of inconveniencing everyone dependent on the old. Eventually that technology can no longer remain on par with the others without such qualms, and it dies.
Its not imo an infrequent occurrence that software authors decide to do things so differently in a new version, that it fundamentally breaks compatibility with the old way of doing things.
Ie python 3 is something different from python 2; just like how in the C world a libXYZ.1.0 may have an entirely different api from a libXYZ.2.0, or how linux 2.6 differs from 2.4 for device driver writers etc; because the developers felt there was a compelling reason/opportunity to do things differently/better as the world moved forward.
In all cases, authors of other 3rd party software somehow dependent on the above (ie python, the hypothetical libXYZ etc) must then decide when/if they will transition to the new way of doing things.
And this in turn will have a knock-on effect on users of that 3rd party software, who in turn may suddenly have some further constraints imposed on them in terms of what they can and can't combine, what additional testing may be required etc.
That is just the price of progress; and frankly I don't see that anything else (Ruby, .NET) is somehow immune to this ever happening.
I build a lot of embedded systems that combine a variety of components, libraries etc, and there are forever dances around picking versions of things to get compatible dependencies, over the whole spectrum of technologies.
There are also always degrees of freedom, ie sometimes you just have to use both the old and new versions to satisfy dependencies for other components, run things as separate executables and then stitch those together via an ipc mechanism.
I don't think its realistic to think anyone's base technology might not ever change incompatibly; and so even though it might bring more work for a while, I don't see this change in python as anything so different from what we deal with anyway elsewhere, that it would merit me to consider for a moment replacing python with something else, either in the embedded environment or elsewhere.
In fact I applaud the python developers for their courage to be able to walk away from old paradigms and cut old cruft.
Maybe in looking at something like Ruby, right now you might feel a pythonista to be at a disadvantage to a rubyist if the latter is perceived as working with a more "stable" (unchanging) platform at this particular moment, and who's to say you're not justified in feeling so; but to my way of thinking it seems virtually assured that at some future point, Ruby will also undergo the same type of thing.
(Or, as tends to happen to those technologies where developers cannot find the courage to walk away from the old, things stagnate and love withers away).
Thus, I do not see this change holding back the evolution of python at all.
In fact I would argue evolution of a technology is held back precisely when the developers thereof cannot bring themselves to do the necessary to replace the old by the new, for fear of inconveniencing everyone dependent on the old. Eventually that technology can no longer remain on par with the others without such qualms, and it dies.
I agree and totally grok why. In an appengine chat I asked Guido directly this question when AppEngine will support Python 3 because after his PyCon speech he was really pushing it. He also stated the difficulties which I totally understand.
But I am not for dropping python older support at all. What I am hoping is there are better ways to install python side by side and within the python program itself it can select the version to use. Therefore you could have apps running 2.5, 2.6, 2.7, 3.1 etc.
Python version 2 only got good around 2.4 2.5 so the same might happen with Python 3 it is just the infrastructure currently in many cases forces you to choose new or old only because there is no easy version picking in many platforms.
AppEngine did recently add the ability to use_library('django','1.0') so I am hoping the same starts happening for Python versions and more people do this as times goes on.
Python is the best programming community and tools are immense (libraries) I just hope we are able to beat the legacy wave. One way is with version picking and side by side installation of different runtimes.
On the flipside there is a big opportunity to make newer frameworks that are able to run on Python 3 with support back to Python 2.6. So let's go make them.
But I am not for dropping python older support at all. What I am hoping is there are better ways to install python side by side and within the python program itself it can select the version to use. Therefore you could have apps running 2.5, 2.6, 2.7, 3.1 etc.
Python version 2 only got good around 2.4 2.5 so the same might happen with Python 3 it is just the infrastructure currently in many cases forces you to choose new or old only because there is no easy version picking in many platforms.
AppEngine did recently add the ability to use_library('django','1.0') so I am hoping the same starts happening for Python versions and more people do this as times goes on.
Python is the best programming community and tools are immense (libraries) I just hope we are able to beat the legacy wave. One way is with version picking and side by side installation of different runtimes.
On the flipside there is a big opportunity to make newer frameworks that are able to run on Python 3 with support back to Python 2.6. So let's go make them.
Right, but that's a different question. It's possible to do one of three things:
1. Stay on 2.x
2. Move to 3.x
3. Simultaneously support 2.x yet also move to 3.x
"Hopefully, even projects like Django could move to 3.x for new releases while supporting 2.x on an older release."
Not really, no. There are two things going on here.
First, many people seem to have a different view of the Python 3.0 migration process, when compared to what's been discussed and planned for by the Python development team. Put simply, nobody who actually works on developing Python expected that this would be a quick transition, and mostly they seemed to expect (and plan for) large projects taking at least a couple years to get to the point of running only on 3.x. That's why there will be a Python 2.7, and possibly a Python 2.8.
The other thing is simply that many end users can't do a quick jump to 3.0 installations and will be pretty upset if they lose new releases of software as a result. So "we're jumping to 3.0, too bad if you can't" isn't an attitude we can take. And, honestly, most of the operating-system vendors aren't going to be there with packaged 3.x Python and packaged 3.x libraries anyway.
So what we're doing is a process of deprecation: one Python version per release. Django 1.1 will be the last release to officially support Python 2.3, Django 1.2 will be the last to support Python 2.4, and so on until we hit Django 1.4 (hopefully) sometime next year. At that point we'll only officially be supporting 2.6 and newer in the 2.x series, distros will have had time to catch up, major installations will have had time to lay out upgrade plans and we'll be at a place where a 3.x port is far simpler to undertake.
Not really, no. There are two things going on here.
First, many people seem to have a different view of the Python 3.0 migration process, when compared to what's been discussed and planned for by the Python development team. Put simply, nobody who actually works on developing Python expected that this would be a quick transition, and mostly they seemed to expect (and plan for) large projects taking at least a couple years to get to the point of running only on 3.x. That's why there will be a Python 2.7, and possibly a Python 2.8.
The other thing is simply that many end users can't do a quick jump to 3.0 installations and will be pretty upset if they lose new releases of software as a result. So "we're jumping to 3.0, too bad if you can't" isn't an attitude we can take. And, honestly, most of the operating-system vendors aren't going to be there with packaged 3.x Python and packaged 3.x libraries anyway.
So what we're doing is a process of deprecation: one Python version per release. Django 1.1 will be the last release to officially support Python 2.3, Django 1.2 will be the last to support Python 2.4, and so on until we hit Django 1.4 (hopefully) sometime next year. At that point we'll only officially be supporting 2.6 and newer in the 2.x series, distros will have had time to catch up, major installations will have had time to lay out upgrade plans and we'll be at a place where a 3.x port is far simpler to undertake.
I didn't mean to imply that projects would want to migrate right now; it will take quite a while before many projects choose to make that transition.
Google App Engine's Python is 2.5. I wouldn't bet on 2.6 becoming available for a couple of years.
Django 1.0 just became available on GAE. I'd hate to see things stop with 1.3.
Django 1.0 just became available on GAE. I'd hate to see things stop with 1.3.
topic in #python on Freenode says: "It's too early to use Python 3.x"
[deleted]
Possibly of interest: Here's a regularly-updated plot by Georg Brandl showing the number of Python 3 packages in the PyPI: http://dev.pocoo.org/~gbrandl/py3pkgs.png
One thing that I don't really understand is why not adopt a new syntax to allow users to specify the version of Python a file should be imported and run under. Just have the interpreter pick 2.X by default, but if there's something like
##python-3.0
In a *nix environment, set the shebang line of the file to point to the precise interpreter you want to use. Any imports that file makes will be from the /usr/lib/pythonX.Y for that version of the interpreter. (In order to get the library installed into that path in the first place, it must have been done via that version of the interpreter specifically, so its quite possible to keep 3.x and 2.x versions of the same library quite isolated).
Of course imports can also come from the local dir, via pythonpath and the various manipulations thereof (buildout, virtualenvs etc), so there are a few degrees of freedom via which to manage things.
May be worth pointing out that a file and all its imports will only be running under one interpreter, so a file running on 3.x (via shebang line, say), will not be able to use a 2.x library (even if placed in the correct path) where the code of that library is fundamentally not 3.x compatible.
Of course imports can also come from the local dir, via pythonpath and the various manipulations thereof (buildout, virtualenvs etc), so there are a few degrees of freedom via which to manage things.
May be worth pointing out that a file and all its imports will only be running under one interpreter, so a file running on 3.x (via shebang line, say), will not be able to use a 2.x library (even if placed in the correct path) where the code of that library is fundamentally not 3.x compatible.
Anyone know what version of Python Mac OS X Snow Leopard will ship with come September?
From some quick searching, a couple people say it's 2.6.1, and at least one person says both 2.6 and 3.
[deleted]
Python 3100 :)