I hope Apple takes this as a reason to upgrade the default Python version installed on OS X, otherwise this could be a needless headache.
Numpy: Plan for dropping Python 2.7 support
51–60 of 390 posts
Re: Numpy: Plan for dropping Python 2.7 support
#52Good. 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…
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.
Re: Numpy: Plan for dropping Python 2.7 support
#53Good. 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…
Until you've used them for a while, you won't believe how pleasant f-strings are. It's worth the upgrade.
Re: Numpy: Plan for dropping Python 2.7 support
#54It would be interesting to see whether Python 2 is the longest supported major version for a programming language.
Python 2 came out in 2000 and goes EOL 2020 I think. Perl 5 was released in 1994 and has no planned EOL date, so it is currently winning by a fair margin.
And 2 vs 1 is really only a licensing issue. Python 1.4, from 1996, is not so different!
Re: Numpy: Plan for dropping Python 2.7 support
#55I've said it before, I'll say it again. I don't care for everything-is-unicode-by-default. You can take my Python 2 when you pry it from my cold dead hands.
You know the phrase, "you don't have to go home, but you can't stay here"? You don't have to move to Python 3, but Python 2 is gonna be EOLed. If you don't agree with Python 3's stances on things, it might be time to find another language entirely.
Nah, I'm sure you will be able to get commercial support for at least another decade.
Re: Numpy: Plan for dropping Python 2.7 support
#56I've said it before, I'll say it again. I don't care for everything-is-unicode-by-default. You can take my Python 2 when you pry it from my cold dead hands.
Yes, one of the most painful aspects of Python 2 to 3 migration.
Of course string encoding is the most painful aspect of migrating from Python 2 to 3. The backwards-incompatible fix to how Python handles string encoding is literally the reason Python 3 exists.
Re: Numpy: Plan for dropping Python 2.7 support
#57I hope Apple takes this as a reason to upgrade the default Python version installed on OS X, otherwise this could be a needless headache.
virtualenv plus virtualenvwrapper makes this really easy... using a virtualenv can be as easy as
workon #{projectname}Re: Numpy: Plan for dropping Python 2.7 support
#58To preempt the inevitable discussion of which version to use, please refer to the amazing FAQ created by Eevee: https://eev.ee/blog/2016/07/31/python-faq-why-should-i-use-p...
As a library writer, I cannot wait until we get rid of this self-inflicted handicap of writing in a subset of two incompatible languages. I'm glad the heavyweights are joining the cause.
Re: Numpy: Plan for dropping Python 2.7 support
#59I've said it before, I'll say it again. I don't care for everything-is-unicode-by-default. You can take my Python 2 when you pry it from my cold dead hands.
You know the phrase, "you don't have to go home, but you can't stay here"? You don't have to move to Python 3, but Python 2 is gonna be EOLed. If you don't agree with Python 3's stances on things, it might be time to find another language entirely.
I think the amount of Python 2 source code existing in the world is too large for Python 2.7.x to stop working. A lot of that code is just never going to get ported to Python 3. Companies don't have the budget to do it. So, somehow there will still be a Python 2 interpreter to run the code, even after 2020.
That said, when nearly all of the Python 3rd-party library developers are targeting Python 3, do you really want to be stuck on 2.x? I think that's going to be the ultimate death of new Python 2.x development. The NumPy example seems typical. I.e. the cost of supporting 2.x is very soon not going to be worth it.
It seems clear to me now that there is not going to be a large faction of 3rd party library developers who refuse to move from 2.x. That is unlike Perl 5. As a Python developer, this is very happy result. The 2 to 3 transition was extremely painful but it appears to be mostly behind us now. Having two separate "flavours" of Python (2.x and 3.x) would have been bad.
Re: Numpy: Plan for dropping Python 2.7 support
#60Good. 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.
I have always been interested in that cycle. We use 2 because NumPy supports it still. NumPy supports it because we use it. If a major library had dropped support earlier on, I am curious what would have happened.