Live data from Hacker News

Numpy: Plan for dropping Python 2.7 support

github.com

71–80 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#71
post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

Wild speculation (I'm relatively new to Python), it might also have to do with the Python community having several personalities.

Python 3 solves a lot of problems for me, as someone who does a lot of NLP work, and generally has to deal with strings from the outside world and multiple languages and all that on a more-or-less constant basis. I imagine it solves some problems for Web developers, too, though possibly to a lesser extent. But I don't see a whole lot of devops people being eager to jump off of Python 2, and I'm not sure I see it solving more annoyances in that domain than the process of migrating to Python 3 would create, either.

Re: Numpy: Plan for dropping Python 2.7 support

#72
post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

If this is the case then wouldn't re-naming it Python 4 shake the negative view of it? Guess it's too late now for Python but I've seen it done in other open source projects and it worked pretty well.

Python 3.4+ doesn't have negative view.

Re: Numpy: Plan for dropping Python 2.7 support

#73
post #57
post #51

I hope Apple takes this as a reason to upgrade the default Python version installed on OS X, otherwise this could be a needless headache.

virtualenv plus virtualenvwrapper makes this really easy... using a virtualenv can be as easy as workon #{projectname}

Yes, but it's great to be able to use Python for simple scripting tasks too. In that context it's way too much to expect a user to download virtualenv, so instead people just write things for 2.x

Re: Numpy: Plan for dropping Python 2.7 support

#74
post #43
post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it. The only thing in the last decade or so of Python3's existence that even got me slightly interested in using it was asyncio, and after looking into it a bit, it frankly seems like more trouble than its worth. I know Py…

For anything non-trivial, 95% of the value is in the library ecosystem. So long as most prominent libraries kept releasing new features for Python 2 and 3, there's inevitably not a big pull factor to upgrade. That's changing as a number of major libraries start to make releases that require Python 3.

From a library maintainer POV, I do want to use Python 3. There's no one killer feature, but rather a bunch of small ones, like more specific exception classes (FileNotFoundError etc.).

But if you want to keep using Python 2.7, no-one will take it away from you.

Re: Numpy: Plan for dropping Python 2.7 support

#75
post #43
post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it. The only thing in the last decade or so of Python3's existence that even got me slightly interested in using it was asyncio, and after looking into it a bit, it frankly seems like more trouble than its worth. I know Py…

> Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it.

It seems pretty clear now that 3rd party library developers are going to stop releasing packages that support 2.x and target only 3.x. Isn't that a bigger problem for Python 2.7 hold outs?

Originally, I was not super excited about Python 3. I liked "print" as a keyword. I liked the space efficiency and speed of latin-1 strings by default. I did a lot of network protocol stuff and bytes() was a pain to use. I knew how to use the 'u' prefix to get unicode when I needed. However, after using Python 3 for a few years now, I find Python 2 clumsy. Print as a function is better. Unicode works better. The implementation is just as fast or faster than Python 2 and getting faster every release. If you tried Python 3 a few releases ago, you should give it another go. It has matured a lot.

Re: Numpy: Plan for dropping Python 2.7 support

#76
After such a long and painful road from 2 to 3, I feel like the Python developers aimed too low in fixing the legacy problems that existed in 2.

All that time for Unicode. Not concurrency or type safety or static guarantees or better lambda syntax or anything fun like that. Just Unicode.

Re: Numpy: Plan for dropping Python 2.7 support

#77
post #43
post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

Frankly, I still haven't seen a single reason to switch to Python3 beyond the fact that the original authors have gotten bored of providing security and bugfix updates and will stop in 2020. That's it. The only thing in the last decade or so of Python3's existence that even got me slightly interested in using it was asyncio, and after looking into it a bit, it frankly seems like more trouble than its worth. I know Py…

Because python3 is the new version.

Re: Numpy: Plan for dropping Python 2.7 support

#78
post #15
post #9

It would be interesting to see whether Python 2 is the longest supported major version for a programming language.

ANSI C (C89), Fortran 66 and COBOL 61 will easily be the most serious contenders.

I think the OP is looking for something a bit different, not oldest supported programming language but longest time between major updates to the language.

This is a bit hard to address because Python does incremental language changes, as well as major changes, while the languages you listed have formal specifications.

Python 2 from creation in 2000 to end of new development will be 19 years.

Fortran 66 was around for 11 years, replaced by Fortran 77 and then Fortran 90, 95, 2003, and 2008. I think those dates are what the OP is looking for.

C89 to C99 was 10 years. Then C11 12 years later.

COBOL 61 was followed by 65, 68, 74, 85, and then the poorly supported 2002 followed by 2014.

I think a better contender is MUMPS, made an ANSI standard in 1995 and ISO standard in 1999. It's still in use in healthcare and financial applications. https://en.wikipedia.org/wiki/MUMPS

Another contender is Rexx, ANSI X3.274 / 1996.

Both Rexx and MUMPS are ranked in the range 50-100 on TIOBE.

Then there's FORTH, with FORTH-79, FORTH-83 (both de facto) and then ANS Forth in 1994. But that might be cheating as I think (based on hearsay) most Forth users specialize their implementations rather follow ANS Forth.

Those are still in reasonably wide-spread use. I think something like ALGOL, last revised in 1973, is outside of what the OP was thinking about.

Re: Numpy: Plan for dropping Python 2.7 support

#79
post #17
post #16

Earlier quoted context omitted.

Yeah, for the longest time everyone kept using library support as an excuse for sticking with 2. But at this point I think it's the exception that a decent Python library doesn't support 3, rather than the rule. The only one that comes to mind for me is fabric, to be honest.

> But at this point I think it's the exception that a decent Python library doesn't support 3, rather than the rule. Right now 187 of the top 200 packages on Pypi support Python 3. https://python3wos.appspot.com/

Infrastructure changes to PyPI made it hard to work out what the top packages are. http://py3readiness.org/ is another effort, which currently lists 345/360 packages as Python 3 compatible.

Re: Numpy: Plan for dropping Python 2.7 support

#80
post #10

Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…

I think there were also more compatibility issues prior to 3.3 (when they started allowing u"") for libraries that did want to support both. It seems like the core team predicted that the most popular migration path for libraries would be `2to3` or something like that, when in fact the single-codebase-supporting-both strategy has been much more popular? Probably the transition would've been easier if everyone had seen that coming.
Post reply on HN