Live data from Hacker News

Numpy: Plan for dropping Python 2.7 support

github.com

331–340 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#331

Earlier quoted context omitted.

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

I dunno, on Arch I've seen several times as Perl 5.x updates roll in, Perl scripts will break on stuff. Especially Perl 5.22 and 5.26.

That's because of binary API changes, and only affects Perl modules with C parts in them. Source compatibility has been preserved at least across the entire 5.x line.

Re: Numpy: Plan for dropping Python 2.7 support

#332
post #187

Earlier quoted context omitted.

Don't forget how nice super().__init__() is.

The double underscore methods are some of the ugliest parts of Python. If they were going to break compatibility, I'd get rid of them too.

I think you're right, only this wouldn't require breaking compatibility. It doesn't even require a python upgrade, you could just make a base class that remaps nicer named functions to the standard ones, like baseclass.is_lower_than = baseclass.__lt__

Re: Numpy: Plan for dropping Python 2.7 support

#333
post #189
post #165

Earlier quoted context omitted.

Perl is a weird language language for you to cite when we're talking about languages that do major transitions well. Perl 6 was created because Perl 5 was an evolutionary dead end, took 15 years, has no adoption, and Perl 5 usage shrunk tremendously in the meantime. Not saying this glibly as I love Perl and I hope Perl 6 sees some adoption, but come on now. Also remember that Perl 5 itself was nearly a complete rewri…

Exactly my thought regarding the need to evolve as a language. Perl is mostly dead because it didn't keep up with the times and I say that as a person who spent a tremendous amount of time learning and using Perl. The Schwartzarian transform was a beautiful thing to behold.

> The Schwartzarian transform was a beautiful thing to behold.

Meh, more like a clutch for systems where you couldn't install List::UtilsBy. (One of my favorite Perl modules of all time.)

Re: Numpy: Plan for dropping Python 2.7 support

#334
post #189
post #165

Earlier quoted context omitted.

Perl is a weird language language for you to cite when we're talking about languages that do major transitions well. Perl 6 was created because Perl 5 was an evolutionary dead end, took 15 years, has no adoption, and Perl 5 usage shrunk tremendously in the meantime. Not saying this glibly as I love Perl and I hope Perl 6 sees some adoption, but come on now. Also remember that Perl 5 itself was nearly a complete rewri…

Exactly my thought regarding the need to evolve as a language. Perl is mostly dead because it didn't keep up with the times and I say that as a person who spent a tremendous amount of time learning and using Perl. The Schwartzarian transform was a beautiful thing to behold.

Perl is born to solve portability and limitation problems of shells (csh, sh, ksh*), awk and sed. People who do not live on the command line can not appreciate the power of perl.

Re: Numpy: Plan for dropping Python 2.7 support

#335
post #189

Earlier quoted context omitted.

Exactly my thought regarding the need to evolve as a language. Perl is mostly dead because it didn't keep up with the times and I say that as a person who spent a tremendous amount of time learning and using Perl. The Schwartzarian transform was a beautiful thing to behold.

> The Schwartzarian transform was a beautiful thing to behold. Meh, more like a clutch for systems where you couldn't install List::UtilsBy. (One of my favorite Perl modules of all time.)

There's 17 years between the introduction of the Schwartzian Transform (1994) and List::UtilsBy (2011 according to CPAN).

Re: Numpy: Plan for dropping Python 2.7 support

#336

Earlier quoted context omitted.

https://www.python.org/dev/peps/pep-0238/ {Describing the old python-2 behavior:} -------- Quote: ------- The classic division operator makes it hard to write numerical expressions that are supposed to give correct results from arbitrary numerical inputs. For all other operators, one can write down a formula such as x y *2 + z, and the calculated result will be close to the mathematical result (within the limits of n…

What's wrong about just `float(a)/float(b)`?

not everything that can be divided can be reasonably cast to a float

Re: Numpy: Plan for dropping Python 2.7 support

#337
post #104
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…

Django has not dropped Python2 yet. Django 2.0 will drop Python2 but that has not yet been released, and Django 1.11 (with Python2) support will be supported in LTS for several years.

Right, though no new python2 compatible features have been added since January.

And Django 2.0 should come out December 1st, so it’s not far off.

Re: Numpy: Plan for dropping Python 2.7 support

#338
post #312
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…

RHEL7 "runs on" Python 2 and is to be supported at least until 2024, so I don't think Python 2 is going away.

At the same time, Red Hat is aggressively switching everything to Python 3.

http://portingdb.xyz

(Red Hat has been one of the primary maintainers of Python 2.7 in the last few years. https://news.ycombinator.com/item?id=7582300 )

The BSDs on the other hand (including MacOS) "run on" Python 2 and haven't made as much progress switching to Python 3.

Re: Numpy: Plan for dropping Python 2.7 support

#339
post #312
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…

RHEL7 "runs on" Python 2 and is to be supported at least until 2024, so I don't think Python 2 is going away.

Extended EOL for RHEL6, which runs on Python 2.6 is in mid-2024, too. Python 2 isn't going to go away for a long time in the enterprise yet.

Re: Numpy: Plan for dropping Python 2.7 support

#340

Earlier quoted context omitted.

> The Schwartzarian transform was a beautiful thing to behold. Meh, more like a clutch for systems where you couldn't install List::UtilsBy. (One of my favorite Perl modules of all time.)

There's 17 years between the introduction of the Schwartzian Transform (1994) and List::UtilsBy (2011 according to CPAN).

Huh. I guess it's one of those cases where once you have a thing, you wonder how you could have gone 20 years without it. :) Although, to be fair, I only started working with Perl (beyond one-liners on the shell) in 2012.
Post reply on HN