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

Numpy: Plan for dropping Python 2.7 support

github.com

Post reply on HN
Print view View original

211–220 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#211

Post by shagie »

qznc wrote: post #93
xapata wrote: post #61

Earlier quoted context omitted.

Which version? Aren't we on Java 9 now?

That is actually Java 1.9. They decided to kind of hide the leading "1." at Java 1.5. https://en.wikipedia.org/wiki/Java_version_history#Versionin...

That was part of Sun's "people pay more attention to the first number" reversioning. Solaris 2.6 was followed by Solaris 7.

This was partly because of the competitors (e.g. IRIX) were raving the first digit with each major version. When Solaris was version 2.6, IRIX was version 6.

As I recall it, Management had less confidence with things called "1.X" or "2.X" than things called "5.Y". So, Sun went through and started dropping the small leading digit from the versions of their products.

Re: Numpy: Plan for dropping Python 2.7 support

#212

Post by [deleted] »

ubernostrum wrote: post #170
reificator wrote: post #47

Earlier quoted context omitted.

That list is of the top packages. If internal Mozilla tools are downloaded enough to become top 200, then either Mozilla is larger than I thought or Python is smaller than I thought.

Download counts -- which usually power "most popular" charts -- are extremely misleading, because usually every run of an automated CI system triggers a download.

[deleted]

Re: Numpy: Plan for dropping Python 2.7 support

#213

Post by reificator »

ubernostrum wrote: post #170
reificator wrote: post #47

Earlier quoted context omitted.

That list is of the top packages. If internal Mozilla tools are downloaded enough to become top 200, then either Mozilla is larger than I thought or Python is smaller than I thought.

Download counts -- which usually power "most popular" charts -- are extremely misleading, because usually every run of an automated CI system triggers a download.

Arguably that works better as an indicator, as you can see which packages are being actively developed with. But that's beside the point.

Are you suggesting that Mozilla's CI system runs so often as to artificially inflate the download numbers of their internal only packages to the top 200 Python packages? Because if so, then my point still stands. Either Mozilla is a lot bigger than I thought or the Python community is a lot smaller than I thought.

I also am of the belief that if any team would think to cache their dependencies, it would be the team behind a modern browser.

Re: Numpy: Plan for dropping Python 2.7 support

#214

Post by JonathonW »

goatlover wrote: post #173
lghh wrote: post #67

Earlier quoted context omitted.

"Python 4?? People have not even migrated to Python 3 yet!"

Or just be like the cool kids and skip a version. Python 5, or name it after the year. Python 2020 sounds exciting enough to make everyone want to upgrade.

Python 3 was codenamed "Python 3000" during design and development.

(It was always intended for the finished product to call itself Python 3.0, though.)

Re: Numpy: Plan for dropping Python 2.7 support

#215

Post by cpncrunch »

ams6110 wrote: post #205
cpncrunch wrote: post #177

Earlier quoted context omitted.

Good point, I didn't realise Perl6 was in a similar situation. However it seems that adoption of Perl6 is very low, so I suspect Perl5 isn't going to get killed off any time soon.

Very little new stuff is being developed in Perl, period. I don't know anyone working in Perl who is not maintaining existing codebases. I haven't heard Perl proposed for anything new in over a decade. That further reduces the motivation to move to Perl 6.

It depends what you're using it for. Certainly it wouldn't make sense to use it for web stuff. However I use perl exclusively for server-side "shell" scripting, and it excels at that. More powerful than bash, less compatibility worries than python (I've had issues even between 2.* versions). If I have perl5.* on a server my scripts work everywhere. I regularly start new server-side scripting projects using perl, including a recent webpage-to-video conversion batch script. To be honest there is no other platform that I would even consider using for this kind of thing. Is there even anything that comes close to perl's cross-platform, rapid development, stability and general compatibility?

Re: Numpy: Plan for dropping Python 2.7 support

#216

Post by SmirkingRevenge »

Figs wrote: post #43
fredley wrote: 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…

There's all the pain of python 2's string/byte handling... is it a byte str? Or unicode code points? Python 2 likes to keep you guessing, and that's not a good thing. If you haven't felt the pain here, there's a good chance your stuff is subtly broken in ways you may not be aware of.

Re: Numpy: Plan for dropping Python 2.7 support

#217

Post by [deleted] »

_wwz4 wrote: post #98
Figs wrote: 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…

[deleted]

Re: Numpy: Plan for dropping Python 2.7 support

#218

Post by blunte »

int_19h wrote: post #195
blunte wrote: post #192

Earlier quoted context omitted.

That's a really poor reason to kill an old version. To be clear, I FEEL YOUR PAIN. However, new isn't legit just because it's new. As a non-Python pro, I cannot say why one version over another. However, arguing that the old one is bad just because it is inconvenient isn't valid. As someone who struggles with versions of Python on my Mac and on production servers (and with code that runs on 2.7 and 3.6+), as far as I…

I think the argument here is that Py3 is better for many people (Unicode-by-default was generally the reason, but these days it's also the numerous language improvements, e.g. async/await). For those who find themselves on the fence with no particular personal reason to go either way, though, going where the others are is a legitimate way to choose.

What we often forget are the large numbers of people who just use Python (or any other tech tool) as a means to an end.

In this case I'm included. Python is not my first, second, or third love. But it is the most available and the simplest tool available to glue things together. CSVs, json, web apis (private and commercial), etc., are all so easy to do with Python.

So my guess is that there are a lot of users who may not even realize the benefits that Python3.x gives vs 2. "We" don't know or care about features we don't need. But we do feel the pain of modules that only work for one version.

In hindsight, I would have voted for a hard break from 2->3 perhaps 2 years ago. I suspect the ultimate human time effort would have been less than we waste now straddling or stumbling with two versions.

Re: Numpy: Plan for dropping Python 2.7 support

#219

Post by mmsmatt »

cyphar wrote: post #164
cpncrunch wrote: post #157

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…

Serious question, what was the complaint against xrange?

I don’t recall it ever surprising me or behaving poorly.

Re: Numpy: Plan for dropping Python 2.7 support

#220

Post by ridiculous_fish »

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 both. This is a terrible state of affairs.

Post reply on HN