This seems to be based on the false Python 3/2 dichotomy.
Python 3 is popular enough that it is effectively unkillable. For exactly the same reason Python 2 is also unkillable.
Language adoption is never a zero sum game.
Google will kill Python 3, and it might be a good thing
11–20 of 25 posts
Re: Google will kill Python 3, and it might be a good thing
#12This reminds me of an old question on reddit after their HPHP compiler was announced and someone said asked if it was going to take erlangs role.
The answer is no, purpose built runtimes do not uproot established projects in another domain, and a proprietary corporate project to migrate legacy code will not fix issues of fragmentation. In fact, it just kinda piles it on.
If you want to see how effective Google has been in fixing long standing python issues, check out the history of the Unladen Swallow project.
Re: Google will kill Python 3, and it might be a good thing
#13This is another python 2 fork that reading this reminded me of: https://github.com/naftaliharris/tauthon
Re: Google will kill Python 3, and it might be a good thing
#14Not true at all. Python3 evolved in leaps and bounds in the last few years gaining many essential features for a modern programming language. Things like async/await, new frameworks showing up all the time shows a growing ecosystem. The fact that Google prefers Go is understandable and does not mean that python's importance is diminished in any way.
Re: Google will kill Python 3, and it might be a good thing
#15Better come over to Perl before it's to late guys ;)
Re: Google will kill Python 3, and it might be a good thing
#16[deleted]
Re: Google will kill Python 3, and it might be a good thing
#17It's bad that the runtime is fragmented. Google will fix it by creating a new runtime
Re: Google will kill Python 3, and it might be a good thing
#18Ha, no. Google can continue toiling away in the caves of antiquarian history if they like, but anyone with half a brain will be using Python 3. All the things mentioned, built in concurrency, speed, easy package management, are all in Python 3. I have no idea why Google doubled down on Python 2.7 years ago. I mean, generally they are competent technical folks. But 2.7 is littered with all kinds of obtuse mis-steps in the development of the language. And it's missed out on the last several years of feature addition to Python 3 (asynchronous primitives among other things). Why would one plant their flag in something like that? And I mean come on... print as a keyword? How can anyone not spit at that?
Re: Google will kill Python 3, and it might be a good thing
#19Google isn't going to "kill" Python 3. This is a relatively niche use case (grumpy only converts Python 2.7 code into Go code, and it's not 1:1 as it's missing features like decorators), and there doesn't seem to be any intention on adding new Python features into grumpy. My guess is that this was made more for Google's purposes of migrating some of their legacy Python 2.7 code to Go, in an effort to move towards Go…
Many courses (even one made in 2016, course.fast.ai) still use Python 2 for some reason.
Even some libraries only support Python 2.
Why can't we move on ;(
Re: Google will kill Python 3, and it might be a good thing
#20(One topic I see being brought up when it comes to runtimes, python 2 and 3 is C API stuff. It still bubbles up to the top now and then. This isn't related to grumpy specifically, but the FUD I've been witnessing)
Maybe I'm far underestimating the amount of custom C API being used in production at places or been hanging out in the wrong places. I just doubt that intention is to kill off anything. Even by unintended side effect.
A great deal of the python code I see with C extensions already is Python 3 compatible and even has wheels for them. I think it used to be numpy and libraries that pulled it in as a dependency. We're at the point where compatibility from 2 and 3 is so darn good in libraries we pull in I hardly notice it anymore. [1]
I do write Python 2 + 3 compatible code. The differences in the syntax itself are trivial. A compat module [2] will do the trick assuming you have your own custom C extensions, which most don't.
(Going off on a bit of a tangent) There has been some deliberation of what has to be done to get around GIL: The other thing is I haven't been convinced of is the idea being thrown around at conferences and on mailing lists that breaking the C API is this world-ending scenario. Yeah I understand the disruption, but what % of the code, assuming you're in the minority of python developers doing custom c extensions, that you can't update some API signatures?
[1] https://python3wos.appspot.com/
[2] http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/...