5 ms·

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 initiat

by whughes 17y ago

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.

mcav 17y ago
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.
uggedal 17y ago
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/0888b1c8f2518059 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.
- mcav 17y ago
  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. That's as close to win-win as you could get.
  - ubernostrum 17y ago
    "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.
    - mcav 17y ago
      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.
    - anamax 17y ago
      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.
- drawkbox 17y ago
  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.
  - bobbyi 17y ago
    Version .6 of SqlAlchemy will support Python 3.
    - drawkbox 17y ago
      I hope others follow very soon.
  - pcc 17y ago
    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.
zain 17y ago
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/gsoc2009/python/t124024625558 http://socghop.appspot.com/student_project/show/google/gsoc2...
deleted 17y ago
[deleted]
swolchok 17y ago
topic in #python on Freenode says: "It's too early to use Python 3.x"

by whughes 17y ago

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.

mcav 17y ago

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.

uggedal 17y ago

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/0888b1c8f2518059 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.

mcav 17y ago
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. That's as close to win-win as you could get.
- ubernostrum 17y ago
  "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.
  - mcav 17y ago
    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.
  - anamax 17y ago
    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.
drawkbox 17y ago
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.
- bobbyi 17y ago
  Version .6 of SqlAlchemy will support Python 3.
  - drawkbox 17y ago
    I hope others follow very soon.
- pcc 17y ago
  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.

zain 17y ago

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/gsoc2009/python/t124024625558 http://socghop.appspot.com/student_project/show/google/gsoc2...

deleted 17y ago

[deleted]

swolchok 17y ago

topic in #python on Freenode says: "It's too early to use Python 3.x"