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

191–200 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#191

Post by pfranz »

gigatexal wrote: post #129
matt_wulfeck wrote: post #88

Earlier quoted context omitted.

There’s really not anything major in 3 that’s not easily available via back ports in 2.7. Or else why do you think people aren’t bothering to pay the price to switch? This is also the reason maintainers are bringing out sticks. They realize the carrots just aren’t that tasty.

Back posting anything to 2.7 was a mistake. It shouldn’t have happened because it offered a crutch to stand on instead of spurring ports to 3. 3.x has been around for years now. There was no excuse to have started porting an application that would have taken 3 or four years to do, 3 or four years ago. What did everyone think that 3.x python was a fad and not going anywhere?

I think it was an all or nothing thing. If they could have packported everything (the whole point of 2.7 was to be a bridge) then everyone would have moved up like they do for every point release. Only backporting the fun stuff left only the not-fun stuff when migrating your code.

Re: Numpy: Plan for dropping Python 2.7 support

#192

Post by blunte »

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

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'm concerned (as a pragmatic solutions-first person goes), I cannot discern the difference between ancient Python and new Python.

There are really few languages with such impact as Python. So we cannot blame the Python community for this situation as they probably really labored over their decisions regarding compatibility and versions. But in retrospect, I would have preferred they killed off the old version long ago. It would definitely have made life better for the users in the long run.

Re: Numpy: Plan for dropping Python 2.7 support

#193

Post by rcpt »

wybiral wrote: post #16
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…

Yeah, for the longest time everyone kept using library support as an excuse for sticking with 2. But at this point I think it's the exception that a decent Python library doesn't support 3, rather than the rule. The only one that comes to mind for me is fabric, to be honest.

It's not just libraries that I use when developing.

Searching for code snippets and copy/pasting stackoverflow answers can easily take more time out of my days than library documentation. But it's so much slower when I have to rewrite something I found for python 3.

Re: Numpy: Plan for dropping Python 2.7 support

#194

Post by bastawhiz »

bandrami wrote: post #158
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!

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?

Re: Numpy: Plan for dropping Python 2.7 support

#195

Post by int_19h »

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

Re: Numpy: Plan for dropping Python 2.7 support

#196

Post by freeone3000 »

user5994461 wrote: post #126
jhasse wrote: post #84

Earlier quoted context omitted.

Most C++ code wont compile for multiple reasons. For example using namespace std will result in errors if your code calls a function which is now part of std.

I actually think that migrating from Qt4 to Qt5 has a lot of similarity with python 2 to python 3. Not sure why there aren't more people doing the comparison.

pyqt is a robust enough wrapper to avoid the migration issues, so in a python thread you won't have anybody who suffered through that mess.

Re: Numpy: Plan for dropping Python 2.7 support

#197

Post by int_19h »

jimmaswell wrote: post #136
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…

When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas. I want to just some input into a string, do some operations on it, and print the result. Now I have to make extra special sure to convert the string between binary or utf8 as appropriate, catch encoding exceptions, not try to print anything that might have bina…

You don't need to do any of that. If you use `input()`, you get a string - all conversions are done for you. If you're reading from a file (or from stdin, treating it as a file object), again, in text mode you just get strings. Same thing for printing - if you print strings, they will get converted to the encoding appropriate for the target terminal.

So, what is it exactly that you're trying to do?

Re: Numpy: Plan for dropping Python 2.7 support

#198

Post by jimmaswell »

int_19h wrote: post #197
jimmaswell wrote: post #136

Earlier quoted context omitted.

When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas. I want to just some input into a string, do some operations on it, and print the result. Now I have to make extra special sure to convert the string between binary or utf8 as appropriate, catch encoding exceptions, not try to print anything that might have bina…

You don't need to do any of that. If you use `input()`, you get a string - all conversions are done for you. If you're reading from a file (or from stdin, treating it as a file object), again, in text mode you just get strings. Same thing for printing - if you print strings, they will get converted to the encoding appropriate for the target terminal. So, what is it exactly that you're trying to do?

IRC logs with IRC control code characters in them don't work nicely with python 3 text strings, for example.

Re: Numpy: Plan for dropping Python 2.7 support

#199

Post by int_19h »

rspeer wrote: post #180
nonbel wrote: post #122

I am a python outsider, but like many others dealt with a lot of pain due to the simultaneous 2 and 3 versions. Looking at the history, I see python1 ended at 1.6, and python2 ended at 2.7. Based on this the current python 3.6 seems to be nearing end of life. https://en.wikipedia.org/wiki/History_of_Python So what will happen when python 4 comes out?

The Python developers plan to never break syntax or stdlib compatibility again. Core developer Nick Coghlan wants to see 4.0 within the decade but he wants it to be "uneventful". [1] In that way, it would be a lot like Python 2.0, which only broke compatibility in obscure ways, but added new ways to do things. Here are some of my wild guesses at what features Python would want to commemorate with a 4.0 release: - An…

> UTF-8 as the guaranteed default encoding, instead of trying to infer anything from stupid locale shit.

This is already the case for source code, right? And I don't see where else it could apply. If you mean stdin/out, then those have to use locale to be compatible with other text-processing software (so that you can pipe things etc).

Re: Numpy: Plan for dropping Python 2.7 support

#200

Post by int_19h »

pdknsk wrote: post #133

I was surprised to recently notice a yellow banner on the website of the very popular Requests library, which urges users to switch to Python 3. That's when I first thought switching may become inevitable. I guess this is being orchestrated behind the scenes now. https://docs.python-requests.org Still, I have no plans to switch. The only useful feature in Python 3 to me is more liberal use of unpacking. Unfortunately…

It has been "orchestrated" ever since PSF announced an official end-of-life date for Python 2.7.

This is just the way things work: support eventually runs out, and if people didn't switch before then for other reasons, that's usually motivation enough to finally do so.

Post reply on HN