Live data from Hacker News

Numpy: Plan for dropping Python 2.7 support

github.com

151–160 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#151

Earlier quoted context omitted.

The following example is pretty much the chief reason why I will not be porting much software to Python 3: $ python3 Python 3.6.3 (default, Oct 3 2017, 21:45:48) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 4/3 1.3333333333333333 Python3 is basically a different language than Python 2. If I wanted to port software to a different language, I would use any number of av…

It is a change, but you can use the // operator for floor division: $ python3 Python 3.6.3 (default, Oct 3 2017, 21:16:13) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 4//3 1

I think you've just proved OP's point...you have to change the code.

Re: Numpy: Plan for dropping Python 2.7 support

#152
post #37
post #23

Earlier quoted context omitted.

Those are internal tools at best so it won't matter that much for migration.

Why are internal tools showing up in the top 200 PyPI package list?

I've wondered that too. Are they automatically downloaded by a Firefox build script, perhaps?

Re: Numpy: Plan for dropping Python 2.7 support

#153
post #78
post #15

Earlier quoted context omitted.

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…

Still, ANSI C89 is still being "developed" in the sense modern optimizing compilers still improve the state of the art and their STD (glibc/musl) still supports them as primary targets for development (rather than the newer C99/C11).

The same is true for Fortran and COBOL. Both are actively being developed as programming languages. Python2 is both a framework (extended std) and language, so the line is blurry. I would even say that Python2, as a language/runtime, has not been under development since quite a while meanwhile C89 development is still going full speed.

Re: Numpy: Plan for dropping Python 2.7 support

#154
post #131
post #108

Earlier quoted context omitted.

Look at the statement from the numpy group: The NumPy project has supported both Python 2 and Python 3 in parallel since 2010, and has found that supporting Python 2 is an increasing burden on our limited resources; That's a real team saying that they just can't support 2 major versions of the language any longer.

That is like the biggest fake argument ever. There is plenty of resources and Python 2 support is neither a burden nor this burden in any way increasing. The are plenty of people ready to step up to continue Py2 support (Even I would be glad to help). This is a pure political decision based on ideology.

As the codebase grows, you need to maintain 2 growing codebases, how is that not increasing the burden?

Official support will be dropped by 2020, by then you will be relying on the community (who ?) to provide bug and security fixes. I'm not aware of anybody stepping up and declaring they will take over maintenance.

At this point, insisting on python 2 is the ideological "side". There's no practical nor realisitic reasoning behind it. Major parts of the community are moving to python 3 and dropping python 2.

You can stay with python 2 and maintain the language / libraries, but don't begrudge those that move on.

Re: Numpy: Plan for dropping Python 2.7 support

#155

Earlier quoted context omitted.

It is a change, but you can use the // operator for floor division: $ python3 Python 3.6.3 (default, Oct 3 2017, 21:16:13) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 4//3 1

I think you've just proved OP's point...you have to change the code.

You have to change the code a lot more to port it to an entirely different language.

Re: Numpy: Plan for dropping Python 2.7 support

#156
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…

Nick Coghlan has written on this extensively: http://ncoghlan-devs-python-notes.readthedocs.io/en/latest/p...

Re: Numpy: Plan for dropping Python 2.7 support

#157
post #98
post #43

Earlier quoted context omitted.

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…

why on earth is it a good thing that people are trying to kill off Python2? Because the community is fragmented and that weakens language adoption, productivity, and enjoyment. The 2-3 schism in Python has been a pain to deal with for years. I use Python casually here and there, but I'm so sick of trying to do something quickly in Python and finding out that I'm on a machine that only has 2 but the module I need is o…

>For the good of any computer language, old versions need to eventually die off.

I would say instead: for any good computer language, new versions need to retain compatibility with old versions. Every single system I run has python 2.7 (including my brand new Macbook running latest OS X). Luckily I don't need numpy, and I can probably do without python at all if I have to.

Compare to perl: I can run old perl scripts on basically any system without having to worry about it breaking. I do all of my server scripting in perl for this reason.

Re: Numpy: Plan for dropping Python 2.7 support

#158
post #7

That’s about the same time python 2 support drops in general. Sounds strange to support packages after the underlying python has moved on. Kudos to the numpy team for writing the most awesome python module under the sun, and for providing great support!

Huh? I'm starting projects in Python 2 because I know for once that the language won't move out from under me. I love it.

Re: Numpy: Plan for dropping Python 2.7 support

#159
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…

We use Appengine, which only supports python 2.7. As well as being a reason for us to stick with 2.7, I imagine Google prefers what is effectively a LTS release. If (hopefully "when") they provide 3.x, they will need significantly more support resources to keep up with continual releases.

App Engine already supports Python 3.
Post reply on HN