Numpy: Plan for dropping Python 2.7 support • Hacker News Board

Re: Numpy: Plan for dropping Python 2.7 support

#231

Post by joshuamorton » Thu, Nov 16, 2017, 5:34 AM UTC

ridiculous_fish wrote: post #220

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/

Re: Numpy: Plan for dropping Python 2.7 support

#232

Post by semi-extrinsic » Thu, Nov 16, 2017, 5:39 AM UTC

cpncrunch wrote: post #215

ams6110 wrote: post #205

Earlier quoted context omitted.

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, 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.

Re: Numpy: Plan for dropping Python 2.7 support

#233

Post by pletnes » Thu, Nov 16, 2017, 5:43 AM UTC

jwilk wrote: post #44

pletnes wrote: 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!

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.

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

Re: Numpy: Plan for dropping Python 2.7 support

#234

Post by cyphar » Thu, Nov 16, 2017, 5:46 AM UTC

mmsmatt wrote: post #219

cyphar wrote: post #164

Earlier quoted context omitted.

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.

The issue is that "xrange" does the right thing, but the seemingly-more-correct (unless you happen to know about "xrange") "range" does the wrong thing (create a list rather than a generator, which is inefficient). Same thing with "raw_input" doing the right thing, but "input" being completely wrong (and an attack vector because it's just a glorified "exec").

Re: Numpy: Plan for dropping Python 2.7 support

#235

Post by dotancohen » Thu, Nov 16, 2017, 5:59 AM UTC

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…

> What exactly makes Python 3.6 a "decent step up" from 2.7?

Proper handling of Unicode, and more sensible distinction between bytes and characters.

Seriously, Python 3 has done that _so well_ that I wish other languages would take notice.

Re: Numpy: Plan for dropping Python 2.7 support

#236

Post by goblin89 » Thu, Nov 16, 2017, 6:14 AM UTC

cdelsolar wrote: post #227

skierscott wrote: post #117

Earlier quoted context omitted.

> what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? Most of mine have to do with developer productovity and I didn’t find until Python 3.5. – @, the matmul operator – fstrings (f”{foo}”) – parameter typing (foo: int = 0) which has exciting work with Cython – other async features. I forget what library it was (tensorflow?) but for Python 3 it had be…

Why is the super().__init__() comment dead below me? In Python 2 you had to do something like super(ClassName, self).__init__(), which is more ridiculous.

This could be because someone flagged the comment. If you believe there’s been a mistake you can vouch for a comment from comment’s page. I did vouch for x14 already—being able to shorten parent’s method calls into super().methodname() minor syntax sugar though it may be is one of the things I’m really looking forward to when I switch to Python 3 at my agency.

Re: Numpy: Plan for dropping Python 2.7 support

#237

Post by knlje » Thu, Nov 16, 2017, 6:20 AM UTC

I'm a researcher and have used exclusively Python 2.7 and NumPy for many years. Originally I ported my codebase from Matlab to NumPy because I wanted to go open source. But it's a very nice thing in science if your code runs perfectly for many years. You don't want to do rewrites. So I feel like I should have stayed with Matlab.

Now that I'm soon forced to do another rewrite, I think I'll just switch to a different language with better future prospects on backwards compatibility. I don't feel that I can trust Python anymore in such things. Any ideas?

Re: Numpy: Plan for dropping Python 2.7 support

#238

Post by interrrested » Thu, Nov 16, 2017, 6:22 AM UTC

knlje wrote: post #237

I'm a researcher and have used exclusively Python 2.7 and NumPy for many years. Originally I ported my codebase from Matlab to NumPy because I wanted to go open source. But it's a very nice thing in science if your code runs perfectly for many years. You don't want to do rewrites. So I feel like I should have stayed with Matlab. Now that I'm soon forced to do another rewrite, I think I'll just switch to a different l…

It is a bit weird to want better support. Version 3 is out for so many years already.

Have you dropped using windows when XP is not supported anymore ?

Re: Numpy: Plan for dropping Python 2.7 support

#239

Post by Rotareti » Thu, Nov 16, 2017, 6:24 AM UTC

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…

> What exactly makes Python 3.6 a "decent step up" from 2.7?

The language and the standard lib improved a lot. There are so many improvements, it would be impossible to list them all after so many years of progress...

Just to name a few of the bigger improvements, that I have discovered recently:

* The typing module lets you add type annotations to your code and write code like this:

    class User(NamedTuple):
        id: int
        name: str
        age: int

    def remove_user(u: User) -> None:
        # ...

    fred = User(123, 'fred', 42)
    # ...
    remove_user(fred)

* F-strigs are awesome:

   file_path = f'{base_dir}/{user_name}/{latest_dir}'

* I think asyncio and the async/await syntax are great.

* The refactoring of the subprocess module:

    subprocess.run(my_cmd)

* The documentation of the standard lib improved a lot, if you ask me.

This is just off the top of my head...

But really, it's the overall improvement of the language and the standard lib that make the difference, not just the big features.

Re: Numpy: Plan for dropping Python 2.7 support

#240

Post by frik » Thu, Nov 16, 2017, 6:28 AM UTC

blunte wrote: post #192

_wwz4 wrote: post #98

Earlier quoted context omitted.

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…

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 can feel the pain of devs that have to deal with Python 2 and 3. To me the beginning of the ugly Python 3.0 announcement was too off putting, it stopped my interest in Python and I went back to PHP, Java and later also NodeJS, Go.

In comparison PHP and Java always successfully transitioned to new versions, keeping it backward-compatible and do baby steps instead of a big incompatible cut. PHP canceled the ill fated PHP6 fork, and went from PHP 5.2 then up to 5.6 and then jumped to PHP7 (as several PHP6 books got published about an alpha version).

Language with a rocky transition (mostly due to incompatible syntax) were C#/dotNet 1->2, Perl 5 -> 6, Lua 5.1 -> 5.3, Ruby 1 -> 2, Swift 1 -> 2 -> 3, Rust 0.x -> 1, and more