Live data from Hacker News

Numpy: Plan for dropping Python 2.7 support

github.com

171–180 of 390 posts

Re: Numpy: Plan for dropping Python 2.7 support

#171
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?

It's been clearly and unequivocally stated that a large breaking transition will not happen again.

Re: Numpy: Plan for dropping Python 2.7 support

#172

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.

The price to switch is too high. A codebase that took years to write will take years to migrate. To make the matter worse, it's impossible to support both python 2 and python 3 at the same time.

I have codebases that took me years to write and took a day or two to port.

Re: Numpy: Plan for dropping Python 2.7 support

#173
post #67

Earlier quoted context omitted.

If this is the case then wouldn't re-naming it Python 4 shake the negative view of it? Guess it's too late now for Python but I've seen it done in other open source projects and it worked pretty well.

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

Re: Numpy: Plan for dropping Python 2.7 support

#174
post #167

Earlier quoted context omitted.

Yes, yes. My Python life is mostly about impelemnting odd protocols with Twisted. Will probably get serious about asyncio soon, but I have a lot of historical Twisted to deal with ATM. I've noticed that the "Who cares about Python 3" types are not the people working on the kinds of problems I am. So my conclussion is that for many kinds of problems the benefits of Python 2 are kind of meh, so people stay in their com…

How is the Twisted Py3 support coming along in practice? It looks like they are steadily ticking items off the todo list, but is it ready for production use yet?

Everything I need is production worthy. That's obviously an idiosyncratic assessment.

Re: Numpy: Plan for dropping Python 2.7 support

#175
post #48
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…

The change to string handling justifies it for me. Writing `u’foo’` everywhere is a pain, and the rest of the 2.7 model is extraordinarily prone to runtime errors. With 3.6, I don’t have those problems.

I have a contrary anecdote: for the sorts of work I do, having to distinguish between strings and bytes makes using Python3 more difficult, and more prone to errors.

I mostly deal with network protocols, lots of numeric content, and scarcely any non-English text.

But I appreciate other people have different needs.

Re: Numpy: Plan for dropping Python 2.7 support

#176
post #166

Earlier quoted context omitted.

I was going for "humor" more than "melodrama," but maybe I failed at both... The actual breaking changes between 2.x and early 3.x struck me as cosmetic and pointless. To compare: Perl went one way by breaking everything to essentially make a new language, and failed to get people to switch; C++ bent over backwards to maintain compatibility, and failed to fundamentally evolve the language. Python basically failed in…

To also compare: Ruby made big breaking changes similar to Python 3 and called it "Ruby 1.9". It wasn't really a big deal. There was some pain and it became essential to have multiple versions of Ruby installed. But I haven't heard of anyone insisting on new code written for Ruby 1.8. So languages can break backwards compatibility once in a while, and it doesn't always have to be the shitstorm it was for Python. Earl…

I was an outsider to the Ruby changes between 1.8 and 2.0, so thanks for the perspective. My sense was that, like modern JS programmers, they were used to constant churn and breakage, so having the language break as well was only a minor additional nuisance. Most of the stuff they used with 1.8 would be "obsolete" in a year or two even without 1.9.

Re: Numpy: Plan for dropping Python 2.7 support

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

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.

Re: Numpy: Plan for dropping Python 2.7 support

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

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

It’s a balancing act. Breaking compatibility creates work, unfixed bugs and design flaws create work, which is more work varies. Retaining compatibility can be, in sum, a harmful decision.

Re: Numpy: Plan for dropping Python 2.7 support

#179

Earlier quoted context omitted.

We use Appengine, which only supports python 2.7. As well as being a reason for us to stick with 2.7, I imagine Google prefers what is effectively a LTS release. If (hopefully "when") they provide 3.x, they will need significantly more support resources to keep up with continual releases.

App Engine already supports Python 3.

Thanks for correcting me - after excitedly checking the docs, the "flexible" service indeed supports 3.0. The managed service is still 2.7, however.

The flexible service is basically running your own instance of appengine on a VPS, which means you have to provision and support the infrastructure. To my mind, that negates most of the advantage of Appengine - if I was happy to do my own system admin, I'd build my own stack on VPS.

Re: Numpy: Plan for dropping Python 2.7 support

#180
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 easy, Pythonic way to opt out of the Global Interpreter Lock. (The GIL clearly isn't going away because so much extension code needs it, but that doesn't mean all code has to suffer from the GIL for eternity.)

- UTF-8 as the guaranteed default encoding, instead of trying to infer anything from stupid locale shit. (This wouldn't break any code that wasn't broken already.)

- More built-in syntax to support NumPy.

[1] https://www.curiousefficiency.org/posts/2014/08/python-4000....

Post reply on HN