Live data from Hacker News

Numpy: Plan for dropping Python 2.7 support

github.com

271–280 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#271

Earlier quoted context omitted.

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?

Re: Numpy: Plan for dropping Python 2.7 support

#272

What is the preferred way to write an end-user program in Python? At least one platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others have 2.x as the default (macOS, other Linux distros). The consequence is that Python scripts which need to "just work" must be written in the intersection of Python 2 and 3, a language for which no interpreters exist (do they?), and which inherits the pitfalls of bo…

#! /usr/local/bin/python3 Also arch is wrong: https://www.python.org/dev/peps/pep-0394/

To be fair that was written _after_ Arch made their choice and if it's not easy to make that choice, it's sure not easy to reverse it either.

Re: Numpy: Plan for dropping Python 2.7 support

#273

What is the preferred way to write an end-user program in Python? At least one platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others have 2.x as the default (macOS, other Linux distros). The consequence is that Python scripts which need to "just work" must be written in the intersection of Python 2 and 3, a language for which no interpreters exist (do they?), and which inherits the pitfalls of bo…

#! /usr/local/bin/python3 Also arch is wrong: https://www.python.org/dev/peps/pep-0394/

[deleted]

Re: Numpy: Plan for dropping Python 2.7 support

#274

What is the preferred way to write an end-user program in Python? At least one platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others have 2.x as the default (macOS, other Linux distros). The consequence is that Python scripts which need to "just work" must be written in the intersection of Python 2 and 3, a language for which no interpreters exist (do they?), and which inherits the pitfalls of bo…

#! /usr/local/bin/python3 Also arch is wrong: https://www.python.org/dev/peps/pep-0394/

[deleted]

Re: Numpy: Plan for dropping Python 2.7 support

#275

What is the preferred way to write an end-user program in Python? At least one platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others have 2.x as the default (macOS, other Linux distros). The consequence is that Python scripts which need to "just work" must be written in the intersection of Python 2 and 3, a language for which no interpreters exist (do they?), and which inherits the pitfalls of bo…

#! /usr/local/bin/python3 Also arch is wrong: https://www.python.org/dev/peps/pep-0394/

[deleted]

Re: Numpy: Plan for dropping Python 2.7 support

#276

What is the preferred way to write an end-user program in Python? At least one platform (Arch Linux) has 3.x set for `/usr/bin/python`, while most others have 2.x as the default (macOS, other Linux distros). The consequence is that Python scripts which need to "just work" must be written in the intersection of Python 2 and 3, a language for which no interpreters exist (do they?), and which inherits the pitfalls of bo…

#! /usr/local/bin/python3 Also arch is wrong: https://www.python.org/dev/peps/pep-0394/

Sure, if you can make up the rules after someone breaks them, then Arch is wrong...

From the linked PEP (emphasis mine)

> end users should be aware that python refers to python3 on at least Arch Linux (that change is what prompted the creation of this PEP)

Re: Numpy: Plan for dropping Python 2.7 support

#277

Earlier quoted context omitted.

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.

Re: Numpy: Plan for dropping Python 2.7 support

#278
post #164

Earlier quoted context omitted.

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

Perl6 is incompatible with Perl5, so they're also going through a similarly painful transition. Everyone waxes lyrical about how Python 2.x was "good enough and why would you change it", but there were several things in Python 2.x that were objectively awful (unicode was broken, iterator variables can leak to the outer scope, division of integers producing integers, xrange, raw_input, mixed indentation "working", etc…

Perl 6 is a different language. Last time I checked there was no plan to discontinue Perl 5.

Re: Numpy: Plan for dropping Python 2.7 support

#279

Earlier quoted context omitted.

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.

Re: Numpy: Plan for dropping Python 2.7 support

#280

Earlier quoted context omitted.

Nonsense. Use six, use tox for testing in both, easy peasy. They're not that different. Plenty of libraries do it. No reason scripts can't too. Plenty do. Specify a "/usr/bin/env python3" shebang if you want to use any cool features like f-strings

Thank you, I appreciate the reply, but taking a bunch of dependencies is not reasaonable. It is as if you said "Does your shell script use associative arrays? Just install bash 4 on your users machines..." tox apparently depends on virtualenv; this is reasonable if your software is primarily Python, but absurd if your package merely uses Python for one-off scripts. macOS doesn't even install pip by default. I guess w…

> Thank you, I appreciate the reply, but taking a bunch of dependencies is not reasaonable. It is as if you said "Does your shell script use associative arrays? Just install bash 4 on your users machines..."

You can writes compatible Python code without using any extensions, I did that myself, but those tools just make it easier.

> I guess what I'm saying is that Python 2 had an opportunity to fill the Perl/sh ubiquity niche (installed by default on Linux/macOS/FreeBSD!), but squandered it with the 2->3 incompatibilities.

Since you mentioned FreeBSD I need to add that while ago they had an effort to remove any scripting language from the base system. So FreeBSD doesn't come with Perl, Python, Ruby etc preinstalled.

Actually, I think that was a really good decision. No need to worry that system depends on some old Python module which if you upgrade, you can break it.

Instead, you need python3.6? You install that version, you realize that something else needs python2.7? You install python2.7 side by side. In fact you can install all available versions without conflicts or worrying that something will break.

Post reply on HN