Hacker News Reader

Comment by pletnes | Hacker News Reader

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!

View on HN

It's not strange. Python developers might declare Python 2.X EOLed, but that won't stop people from using it. Like it or not, Python 2.X is not going away.

There are big companies with huge legacy 2.x codebases who will stall as long as possible. But popular libraries are dropping 2, and many new libraries aren’t supporting it to begin with. Python 2 is accelerating toward irrelevance.

You make it sound like they're holding out of some weird sense of spite. It's more reasonable to assume most large or small companies still using 2.x have not prioritized upgrading over, I don't know, staying in business?

As large libraries drop 2.x support over time they'll have to prioritize upgrading.

> have not prioritized upgrading over, I don't know, staying in business?

Banks use the very same excuse for a long time, which is why they can't even find Cobol devs to do the work. Bottom line: if having some new grad developer convert Python2 to 3 for some legacy shit would put you out of business, you're already well on your way out.

Sure, and nothing prevents those people from grabbing the last 2-compatible numpy version.

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.

How do you plan on getting on when packages from PyPi stop supporting Python 2 at all? When Django, flask, numpy, requests, pandas, and more just don't even install? Will you just use ancient versions?

I don't understand: are you saying package authors are going to retroactively remove Python 2 support from existing versions? Why on earth would they do that?

Scheme that I wrote in the 1980s still runs (and is running today in commercial systems). I have so little patience at this point for this "higher version = better" nonsense.

And what happens when security issues are inevitably discovered in the libraries that are not updated anymore? Sure it's probably OK if you write things that never interface with a network.

Yes, no doubt there's going to be a crippling security vulnerability in this linear algebra library I use. Come on, you don't really believe that, do you?

I hope you don't use cryptography then, or networking, or image/file manipulation, or do anything with untrusted user input.

If you're only doing algebra on an air gapped computer then why do you even worry? Programming languages and tools will evolve but nobody is forcing you to. Keep a local copy of what you need and be happy. Just don't assume any new libraries you might need will support your stack forever.

Still nowhere near as worrying as the business risk inherent in writing on a moving platform.

Even if you are using Linear Algebra, older versions will not be optimized for newer architectures and instruction sets. This is a problem.

If they're not calling my own ATLAS then they aren't "optimized" in any real sense to begin with.

Will you backport security fixes and other significant bugs yourself?

I don't have do that for my 20 year old Perl code or 30 year old Scheme code. Is the bare-bones Python interpreter really that much more full of vulnerabilities?

Also, Python is the only ecosystem I know of where people actually get angry that you use an old and stable version of the software, as those downvotes indicate.

Python might be an especially loud case, but I've seen a fair amount of that in some other areas, for example:

- People getting angry at browser JS authors for coding in explicit support, or huge back-compat shims, for obsolete browsers and/or deprecated JS features.

- People getting angry at Perl authors for writing code that depends on a stable hash iteration order (changed in Perl 5.26 or something? I forget). There was an extremely vocal (tiny) minority of users raising a big stink about the change in that behavior and claiming that it would break the universe.

- C developers being criticized for coding to older (and often more verbose or tricky to use, but omnipresent) pure-POSIX macros and behavior rather than $latest_GNU_or_GCC_feature, which also had the pernicious effect of making things less portable, and damaging the culture of portability.

There are more examples, but you get the idea.

Reply on news.ycombinator.com