3 ms·

> So I hope "Python 2.8" gets a cool name, perhaps even some funding from a company who wants to keep their Py2.7 code alive and invigorated, and the community

by js8 10y ago

> So I hope "Python 2.8" gets a cool name, perhaps even some funding from a company who wants to keep their Py2.7 code alive and invigorated, and the community part as friends. It has already been explained elsewhere in this discussion by other people, I would strongly advise against that. If you for whatever reason have to stay on 2.7, then make sure your new code is 2.7 only (and best if it works with 3 without changes if you decide to change your mind later). Consider what's more likely in the far future (after PSF will give up on 2.7 support in 2020). That somebody will support 2.7 as it is, or that this guy will support his Python 2.8 hybrid? Also consider what happens (in the far future) when some library you use will drop Python 2 support. It's not likely it will be easy to run on this Python 2.8 hybrid, either. And if you for any reason must use Python 3 features in your code base, just bite the bullet and port it.

dagss 10y ago
What I was hoping for was a sane migration path to prevent the split you talk about in 2020...somebody made a superset of both py2 and py3 that lets one move gradually. If support ends/project dies one would bite the bullet and move all the way to py3 I guess. My py2 code uses unicode properly which may color my view a bit... But I don't really disagree with what you say.
- pfranz 10y ago
  Clearly, "sane" is up for argument. My understanding is that 2.6 was the last version to get major features. Python 2.7's goal was to be a bridge between 2x and 3x[1]--it was that superset where code can run in both. It back ported many of the popular Python3 features (at the time). But that was 6 years ago and Python 3 has had new features since then. (Looking at this from the perspective of the "Python Community" or someone who's goal is to adopt Python3) His focus is to back port newer Python 3 features developed since then. Does this help people move to Python 3? Good on him for digging into cpython. While there's __future__ and the backports module, he seems to have focused on features that aren't just new libraries (which is cool). A few years ago I was trying to backport Python 3's Namespace Packages for my company since our internal import tools effectively do the same thing (except our's had bugs). [1] https://docs.python.org/dev/whatsnew/2.7.html#the-future-for-python-2-x https://docs.python.org/dev/whatsnew/2.7.html#the-future-for...

by js8 10y ago

dagss 10y ago

What I was hoping for was a sane migration path to prevent the split you talk about in 2020...somebody made a superset of both py2 and py3 that lets one move gradually. If support ends/project dies one would bite the bullet and move all the way to py3 I guess. My py2 code uses unicode properly which may color my view a bit... But I don't really disagree with what you say.

pfranz 10y ago
Clearly, "sane" is up for argument. My understanding is that 2.6 was the last version to get major features. Python 2.7's goal was to be a bridge between 2x and 3x[1]--it was that superset where code can run in both. It back ported many of the popular Python3 features (at the time). But that was 6 years ago and Python 3 has had new features since then. (Looking at this from the perspective of the "Python Community" or someone who's goal is to adopt Python3) His focus is to back port newer Python 3 features developed since then. Does this help people move to Python 3? Good on him for digging into cpython. While there's __future__ and the backports module, he seems to have focused on features that aren't just new libraries (which is cool). A few years ago I was trying to backport Python 3's Namespace Packages for my company since our internal import tools effectively do the same thing (except our's had bugs). [1] https://docs.python.org/dev/whatsnew/2.7.html#the-future-for-python-2-x https://docs.python.org/dev/whatsnew/2.7.html#the-future-for...