3 ms·

I don think it should surprise anyone here that users with enterprise-size Python codebases aren't jumping to Python 3. PEP 373 doesn't end support until 2015,

I don think it should surprise anyone here that users with enterprise-size Python codebases aren't jumping to Python 3. PEP 373 doesn't end support until 2015, and I assume at that point RHEL or maybe even someone in the python community will pick up the torch (a la Rails LTS). I think by far the more interesting question is what is going on with today's green-field projects (a.k.a. the enterprises in the making). Whoever steps forward to maintain 2.7 long-term will probably be charging an arm and a leg (Red Hat I'm looking at you) and so of course this is unaffordable for bootstrapped companies and ordinary folks will not be able to afford a security patched Python 2 install. Meanwhile the statistics I've seen for green-field development are mixed-to-promising for Python 3. I know for my new projects I'm over 50% 3.3. And when the shoe drops with 2.x support EOL, I think that's going to give it a serious kick.

lars_francke 13y ago
Some support for your point regarding the LTS: The yet to be released RHEL 7 still has Python 2.7.5[1] bundled and not Python 3. RHEL 5 & 6 are being supported for 10 to 13 years[2]. I'd assume that RH will provide any improvements made though - aren't they even required to? [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/7.0_Release_Notes/index.html https://access.redhat.com/site/documentation/en-US/Red_Hat_E... [2] https://access.redhat.com/site/support/policy/updates/errata/ https://access.redhat.com/site/support/policy/updates/errata...
- happycube 13y ago
  At the very least, they have to do security fixes.
shadowmint 13y ago
Which statistics? I'm honestly curious. I presume you've read http://blog.startifact.com/posts/python-2-gravity.html http://blog.startifact.com/posts/python-2-gravity.html? All the new python3/python2 libraries I've noticed adhoc recently have been doing the horrible 'polyglot' one-code-base-support-python2-and-python3 thing, or been in python2.
- jofer 13y ago
  What's horrible about the "polyglot" approach? Beyond not getting to take full advantage of python3, it's really a relatively painless solution (though when you hit the pain points (bytes vs strings vs unicode) you'll notice).
  - shadowmint 13y ago
    There's nothing particularly wrong with it (honestly polyglot should have been python 3.1, with new features at they rolled to 3.2, 3.3, etc. in my opinion); but if the reason for using python 3 is that it has shiny new features (like async io), it's a bit of bummer because you can't use them if your library is py2 compatible. ...which kind of makes it 'python 3 but actually python 2 running on the python 3 runtime', and the code is harder to maintain than either python 2 or python 3 (twice as much testing to do too). Not really much of a carrot for library developers to support python 3.
    - jofer 13y ago
      Very true. It's still better than the option of maintaining two separate codebases, i.m.o., though.
    - zzzeek 13y ago
      what kind of library could transparently use async IO, or not, based on platform? using explicit async for anything dramatically changes the behavior and public API of the code. there is of course a huge carrot for library developers to support python 3 which is, so that python 3 users can use your library, rather than having all of your work replaced by something else and generally holding back the community.
- zzzeek 13y ago
  > All the new python3/python2 libraries I've noticed adhoc recently have been doing the horrible 'polyglot' one-code-base-support-python2-and-python3 thing, or been in python2. uh, what's better? two codebases? heh, hardly. Trust me.
- 13y ago

lars_francke 13y ago

Some support for your point regarding the LTS: The yet to be released RHEL 7 still has Python 2.7.5[1] bundled and not Python 3. RHEL 5 & 6 are being supported for 10 to 13 years[2]. I'd assume that RH will provide any improvements made though - aren't they even required to? [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7-Beta/html-single/7.0_Release_Notes/index.html https://access.redhat.com/site/documentation/en-US/Red_Hat_E... [2] https://access.redhat.com/site/support/policy/updates/errata/ https://access.redhat.com/site/support/policy/updates/errata...

happycube 13y ago
At the very least, they have to do security fixes.

shadowmint 13y ago

Which statistics? I'm honestly curious. I presume you've read http://blog.startifact.com/posts/python-2-gravity.html http://blog.startifact.com/posts/python-2-gravity.html? All the new python3/python2 libraries I've noticed adhoc recently have been doing the horrible 'polyglot' one-code-base-support-python2-and-python3 thing, or been in python2.

jofer 13y ago
What's horrible about the "polyglot" approach? Beyond not getting to take full advantage of python3, it's really a relatively painless solution (though when you hit the pain points (bytes vs strings vs unicode) you'll notice).
- shadowmint 13y ago
  There's nothing particularly wrong with it (honestly polyglot should have been python 3.1, with new features at they rolled to 3.2, 3.3, etc. in my opinion); but if the reason for using python 3 is that it has shiny new features (like async io), it's a bit of bummer because you can't use them if your library is py2 compatible. ...which kind of makes it 'python 3 but actually python 2 running on the python 3 runtime', and the code is harder to maintain than either python 2 or python 3 (twice as much testing to do too). Not really much of a carrot for library developers to support python 3.
  - jofer 13y ago
    Very true. It's still better than the option of maintaining two separate codebases, i.m.o., though.
  - zzzeek 13y ago
    what kind of library could transparently use async IO, or not, based on platform? using explicit async for anything dramatically changes the behavior and public API of the code. there is of course a huge carrot for library developers to support python 3 which is, so that python 3 users can use your library, rather than having all of your work replaced by something else and generally holding back the community.
zzzeek 13y ago
> All the new python3/python2 libraries I've noticed adhoc recently have been doing the horrible 'polyglot' one-code-base-support-python2-and-python3 thing, or been in python2. uh, what's better? two codebases? heh, hardly. Trust me.
13y ago