This seems weird to me. Won't this cause a fork in Python at some point, where the 2.7 developers continue on 2.8 or rename it entirely, and another fork continues on what is now Python 3?
Extend Python 2.7 life till 2020
51–60 of 286 posts
Re: Extend Python 2.7 life till 2020
#52Earlier quoted context omitted.
Just the entire OOP system changed. However, nobody noticed because nobody used the OO features in PHP4.
To this day, old PHP 4 objects code still works in the lastest PHP version The difficulty of upgrade for PHP didn't come from the devs having to redo / revalidate parts of their code for little to no immediate benefit (like in Python's case) but in the shared hosting companies (un)willingness to make the upgrade when the scripts their users wanted (phpbb, wordpress, ...) worked fine with PHP 4. And that's why these v…
I know of a small company (won't publicly shame them) that to this day is actively developing a php 4 code base. The reason is that they use a couple of libraries which do not work in php 5 and don't have the time/manpower to port it.
Re: Extend Python 2.7 life till 2020
#53I just got back into some Python programming after a 2+ year hiatus from the language. I'm stunned that this 2.x vs 3.x debate is still happening and that 99% of all libraries in use * haven't been converted to 3.x. I like the language, but ... damn... If it weren't for the scikit/numpy stuff, I'd stick with Ruby. The Ruby community seems much less fragmented and wants to see the language move forward. It helps a lot…
This is completely not true, on PyPi there are more libraries supporting 3.x than 2.x. The only major 2.x packages that I can think of that haven't been ported are twisted and gevent(?). http://python3wos.appspot.com/
And in Python 3.4+, much of the async functionality of Twisted will also be available in the Python standard lib itself (asyncio, Tulip, http://legacy.python.org/dev/peps/pep-3156/).
Re: Extend Python 2.7 life till 2020
#54Earlier quoted context omitted.
To this day, old PHP 4 objects code still works in the lastest PHP version The difficulty of upgrade for PHP didn't come from the devs having to redo / revalidate parts of their code for little to no immediate benefit (like in Python's case) but in the shared hosting companies (un)willingness to make the upgrade when the scripts their users wanted (phpbb, wordpress, ...) worked fine with PHP 4. And that's why these v…
I know of a small company (won't publicly shame them) that to this day is actively developing a php 4 code base. The reason is that they use a couple of libraries which do not work in php 5 and don't have the time/manpower to port it.
Automattic isn't a small company.
Re: Extend Python 2.7 life till 2020
#55This is a result of some not so optimal design decisions in the past. I remember, when Py3 first came out, everything was incompatible -- unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped. Unnecessary incompatibilities in the C-extension-module implementation layer. And so on. The list of incompatibilities was just huge. Later several of them where dropped, like the strin…
> unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped I mean a hard difference between a string and bytes and strings being utf-8 by default seem to be a necessary (and good) reason?
But unicode strings are the default in Python 3, so they could have kept the 'u' syntax and just let it be a no-op. I think that's what was meant.
Re: Extend Python 2.7 life till 2020
#56This is really disappointing to see - I fear that it will slow adoption of Python 3 even further, when it was just reaching a tipping point[0]. When I first learned Python, I learned Python 3 first because it was newer, and I figured everyone would be using it soon enough. Little did I know that Python 2 would continue to be supported for over ten years after that! Some people make a big deal about figuring out "whic…
On the other hand, if you are comfortable with Python 2, it will do the job, and you know it will be supported for a foreseeable future, why bother learning Python 3? I assume there is a good answer for switching to Python 3, but I honestly don't know (haven't bothered to do any research though). Harshly put: I care about getting my python script working as soon as possible and for a foreseeable future - I couldn't c…
Well, the one big reason was that you were going to lose support for Python 2. Guido just took that reason away and now tens of thousands of new Python apps are going to be written in Python 2 because they've got another 6 years to worry about it.
Guido just created a bigger problem. No good deed goes unpunished.
Re: Extend Python 2.7 life till 2020
#57Anyone know if RHEL 7 will ship with Python 3 in the base, even if not default? That could go a long way to boosting Python 3 adoption.
I know it's in SCL, but that lacks convenience for a lot of users.
Re: Extend Python 2.7 life till 2020
#58I see many comments talking about how this will slow down the migration process. But I don't think the situation is that bad. Most of the py3 wall of superpowers is now green ( https://python3wos.appspot.com/ ) with boto, mysql-python, nltk, python-openid being some of the rare few in terms of not having great py3 alternatives. And most of these have ports on the way already. So one interesting effect of this is that…
boto.mws is absolutely essential for e-commerce on Amazon. I can't even think of moving to 3.x because of that. Not to mention other critical components like Excel processing etc. 2->3 is a major problem in Python, can't understand the thinking behind breaking that much compatibility. Compare this to Java.
Re: Extend Python 2.7 life till 2020
#59Anyone know if RHEL 7 will ship with Python 3 in the base, even if not default? That could go a long way to boosting Python 3 adoption. I know it's in SCL, but that lacks convenience for a lot of users.
RHEL 7 will ship with Python 2.7.5. There is no mention of Python 3 in the release notes.
https://access.redhat.com/site/documentation/en-US/Red_Hat_E...
Re: Extend Python 2.7 life till 2020
#60Earlier quoted context omitted.
> unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped I mean a hard difference between a string and bytes and strings being utf-8 by default seem to be a necessary (and good) reason?
But unicode strings are the default in Python 3, so they could have kept the 'u' syntax and just let it be a no-op. I think that's what was meant.
Right. And they even changed it, I think in Py3.3 -- but that was very late, when many people already decided not to port.