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?
Numpy: Plan for dropping Python 2.7 support
171–180 of 390 posts
Re: Numpy: Plan for dropping Python 2.7 support
#172Earlier 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.
Re: Numpy: Plan for dropping Python 2.7 support
#173Earlier 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!"
Re: Numpy: Plan for dropping Python 2.7 support
#174Earlier 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?
Re: Numpy: Plan for dropping Python 2.7 support
#175Earlier 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 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
#176Earlier 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…
Re: Numpy: Plan for dropping Python 2.7 support
#177Earlier 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…
Re: Numpy: Plan for dropping Python 2.7 support
#178Earlier 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…
Re: Numpy: Plan for dropping Python 2.7 support
#179Earlier 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.
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
#180I 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?
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....