Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Extend Python 2.7 life till 2020

hg.python.org

Post reply on HN
Print view View original

281–286 of 286 posts

Re: Extend Python 2.7 life till 2020

#281

Post by yuhong »

claudex wrote: post #263
yuhong wrote: post #222

Earlier quoted context omitted.

> which AFAIK depending on how much you pay them they support for 13 years 10 years actually. This is a common misconception from those who do not read the lifecycle page carefully.

It's 13 years with the Extended Life Phase and the Extended Life Cycle Support subscription which provide security fixes https://access.redhat.com/site/support/policy/updates/errata...

Except ELS applies only to RHEL3/4 (which gets only 7 years of support otherwise) and also covers a limited amount of packages.

Re: Extend Python 2.7 life till 2020

#282

Post by tshepang »

Igglyboo wrote: post #46
crusso wrote: post #45

I 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/

You are reading that wrong. Having 3.x support does not imply lacking 2.x support. In fact, I believe all those libraries support both 2.x and 3.x.

Re: Extend Python 2.7 life till 2020

#283

Post by tshepang »

BuckRogers wrote: post #276
randomsearch wrote: post #259

Earlier quoted context omitted.

> Will Python 2.x ever die? My guess would be that Python 2.x will die at the same time that Python dies, i.e. the "transition" to Python 3 will never really happen, and part of the reason that Python will die is the split between 2 and 3. I don't think it was obvious that Python 3 would "fail" in this sense, but it seems pretty likely now. Sympathy with Guido; this is essentially a cultural problem rather than a tec…

They're not going to sort out the mess. GVR is 100% stubborn on having 2 and 3 live alongside each other till everyone moves to 3. He won't be combining them in any way in a Python 4.0 and slowly removing the Python2 stuff. I personally won't be moving till GAE, Azure, Amazon, PyPy, PyInstaller, and all Linux distros make the jump. Which at this rate appears to be never. I'm going to do exactly what you're suggesting…

"never" is a very strong word:

* PyPy has a 3.x branch, which is apparently nearly complete

* Major distros, Ubuntu and Fedora, are also moving; Debian is also discussing it

Re: Extend Python 2.7 life till 2020

#284

Post by TheCoelacanth »

collyw wrote: post #278
tonyarkles wrote: post #122

Earlier quoted context omitted.

On both OSX and many Linux distros, Py 2 comes pre-installed but Py 3 does not. If I'm going to write simple scripts that I'm going to give out to people, it's nice not having to worry about them needing to fuck around to get the script to run.

sudo apt-get install python3. Or Whatever the OSX equivalent is. Its not that difficult. Arch comes with Python 3 as default.

OSX doesn't come with a package manager.

Re: Extend Python 2.7 life till 2020

#285

Post by tonyarkles »

collyw wrote: post #279
tonyarkles wrote: post #220

Earlier quoted context omitted.

I totally agree. However, until Py3 is packaged standard it's always going to be easier to run Py2 code. For example, I have a friend who does data analysis on OSX and occasionally she gets data in a format that is ugly. I take a look at it and send her a python script that will massage it into something nice. She's ok with the occasional "sudo pip install ..." to get a library, but if my instructions started with "o…

Simple script like that are unlikely to be much different between Python 2 and 3 unless you are using specific libraries. Just make make all the "prints" into "prints()" and "Exeption, e" into "Exception as e", and I can't see what the differences would be.

The difference is in the effort required to make it run at all!

Re: Extend Python 2.7 life till 2020

#286

Post by reality_czech »

mwcampbell wrote: post #217
reality_czech wrote: post #86

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…

As much as I'm drawn to languages such as Go that are designed for ahead-of-time compilation to self-contained executables, I don't buy your claim that dynamic languages are particularly susceptible to degeneration. As others have pointed out, Java and C++ are both statically typed, and they've both accumulated considerable cruft over the decades. Go is cleaner primarily because it's newer.

C++ was a mess on day 1 due to the decision to build a sorta-kinda higher level language on a C foundation that was never meant to be used that way. The fact that it was designed by a committee and animated by a philsophy of "features, features, features" pretty much explains everything you need to know about what's wrong with it. Does it really count as degeneration when you're born with the defect?

Java hasn't really acquired that much "cruft." The cruft that it does have is mostly relics of really poor design decisions that were made (again) on day 1. For example, the decision to support thread cancellation, which the designers later realized was dumb, has left a bunch of defunct APIs in the Thread class which you're now not supposed to use. I already talked about how the need for jar compatibility (due to the misguided portability religion) led to the generics issues. Java is an ugly language in some ways, but you can't really say that it degenerated: it was that way from the beginning. In fact, now is probably the prettiest it's ever been (not saying much).

Post reply on HN