Live data from Hacker News

Extend Python 2.7 life till 2020

hg.python.org

111–120 of 286 posts

Re: Extend Python 2.7 life till 2020

#111

This 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…

I chose to learn Ruby in part because of the confusing Python 2/3 issue. I recognize that this is a largely stupid reason to choose a language, but when lots of people suggest that either language is great to pick-up, well, it was another easy reason to lean Ruby over Python.

Re: Extend Python 2.7 life till 2020

#112

This is the path that all dynamically typed scripting languages must follow. Over time, change becomes impossible because the lack of typechecking or static analysis tools means that any change might break something in a subtle and hard-to-diagnose way. And so the language grows by accretion. You end up with something like bash or perl, where there are a million ways to do any one thing. Each way was added at a parti…

It is easier. On the other hand, Java doesn't drop any deprecated API's either, so static types may not help as much as you think. Migration still has to happen before dropping something. It seems to be that automatically upgrading your code, even with "go fix", is staying on the hamster wheel. Using a stable language like Python 2.7 is getting off the hamster wheel, since the "hipster" programmers (including me, som…

The risk/reward ratio is a lot different in those two cases. If a Java library drops support for some API (and many do, in major versions), I will know at compile time, and fix it. If the same thing happens in Python, you may not know until days have gone past and your program crashes. The type system is like a set of unit tests that get written automatically and have 100% coverage.

There is also the issue of how code gets installed on the system. The Python model is that you have a bunch of py files sprinkled throughout the filesystem. In this case, you have a "baling out the ocean with a teaspoon" issue when making a major change. There has to be a flag day when everything changes at once. In contrast, with Go, I can have apps compiled with Go 1.0, Go 1.1, and Go 1.2 co-existing happily on the same system. They don't share library files. (Yes, I understand abut things like virtualenv, but that doesn't help distributions that want to ship your software.)

A big part of why Sun (and now Oracle) has been so conservative about backwards compatibility in Java proper (as opposed to the libraries and ecosystem) is because JDK upgrades have a similar "baling out the ocean with a teaspoon" property. It's all or nothing... you generally only have one version of Java installed, and it has to play nice with everything. If they had integrated the runtime into the binary like Go did, this would be much less of an issue.

Re: Extend Python 2.7 life till 2020

#113

Earlier quoted context omitted.

Also fabric, supervisor, graphite, gevent, eventlet, Twisted, etc. The list is still too long.

IMHO there are great py3 alternatives for all of those. Which won't help you when porting, but it won't stop new applications from starting in py3 and will move the process further.

Alternatives don't help when some other project depend on a package that is not fully ported. And this is a problem. It is still a bit harder to quickly build something using Python 3.x. Check trending Python repos for this month:

* portia doesn't work in 3.x because of scrapy, twisted and scrapely;

* psdash - developers don't care;

* jasper-client - developers don't care;

* ansible - Paramico was not ported when development started, now it is a big task to port ansible;

* scrapy - depends on twisted;

* heartbleed-masstest - developers don't care;

* planout - developers don't care;

* beets - not sure what's the reason, either some dependencies or developers don't care;

* reddit - no reason to move for 3.x for a large codebase which is not a library;

* salt - docs says it needs Python * pacemaker - developers don't care;

* pyjvm - developers don't care;

* sentry - large codebase which is not a library.

That's not bad (12 trending packages have 3.x support, 13 don't). But clearly something stops some new packages from starting in py3, and many packages that people find interesting don't work in 3.x. I think that the only way to improve this is to help porting "base" packages that ecosystems depend on; just providing alternatives is usually not a good answer.

Re: Extend Python 2.7 life till 2020

#115
post #102

Speaking as a Python outsider, this looks pathological. If backwards compatibility is such a big hindrance in switching from 2 to 3, why not ship a v2 legacy fallback interpreter along with the new stuff? If you wanted to make it fancy, you could even make a 3-to-2 bridge that allows people to run v2 code from v3. Am I missing something here?

Hm that does sound clever. A preparser to determine what language version then invoke that interpreter. And if the 3 is so good people would switch over to usong its features only very soon.

Maybe py3 just doesnt have good enough features compared to 2 for people to make the switch and shouldnr have existed in the first place?

But gradually introducing changes.

Now python is for all intents two languages instead of one.

Re: Extend Python 2.7 life till 2020

#116
post #74

How I'm not surprised. Python 3 didn't offer anything that would have been so useful and desirable that people would've jumped on it the moment it was released. In fact, it was actually a bit worse than Python 2 when it was out and those Python 2 users could continue enjoying loads of libraries to go with, and of course they knew how to navigate around Python 2's quirks so why bother. Sadly, this is still what I thin…

Try Python 3.4 I agree with the sentiment, and 3.2 had some rough edges still, 3.3 is better and 3.4 finally gives a virtualenv similar (or even better) to Python 2

Still sucks when youve got modules with c extensions, lile any usable fast module, the virtualenv doesnt virtualize that.

Re: Extend Python 2.7 life till 2020

#117
post #34

Earlier quoted context omitted.

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…

" why bother learning Python 3?" Unicode And of course, you'll move from a platform that's shutting down to one that's evolving Really, it's worth it.

Not to mention `yield from`, which is awesome. Iterators everywhere is a powerful tool.

Re: Extend Python 2.7 life till 2020

#118

This 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…

I have to continue to beat the drum of gradual upgrades, Py3 features should and now will be slipstreamed into 2.N, this is a good thing.

https://pythonhosted.org/six/

This isn't disappointing, it is refreshing. Python is dead, long live Python.

Post reply on HN