[1] * Fragmentation of package managers: Pip, Conda, etc.. * Fragmentation of runtime: Pypy, CPython, Jython, Cython, etc.. * Golang (and probably Grumpy in the future) doesn't suffer from these issues, because a central entity (Google) is leading it.
[2] https://github.com/google/grumpy
Yes there will be legacy code that will remain on python2 for ever, but this is normal.
I am personally loving the new features of python 3.6 in particular and would not want to look back.
Google has a lot of code in python2 they want to move to go. It would be bizarre to see anyone start a new project in python 2 because of grumpy.
Love the python community. The future is python3. Enjoy!
Grumpy will primarily make a difference for people who think they're Google, I can't imagine it'll be widely adopted.
That said, my personal feeling is that with awesome new toys like curio, Python 3 is finally starting to be worth the pain of cutting over.
Personally, as of PyCon last year, I do not think it's controversial anymore. If anything still doesn't support Python 3, it's at the service, such as AWS Lambda. The libraries have all transitioned by now [1].
The other thing, arguably more important, is that there isn't really a community around grumpy, whereas there is around Python 3 (the latest nontrivial commit was 3 weeks ago for grumpy, whereas the latest nontrivial commit was 6 hours ago for Python). Even if Google did try to build a community, many people worry that Google will just abandon software when they want to, so people would be hesitant to work with this software long term, which means developers wouldn't want to build any software for it; the majority of developers developing new Python code are doing it in Python 3, and those that aren't are most likely using six rather than only 2.7 unless they're supporting a legacy codebase that either they don't want to or cannot upgrade to Python 3 or to upgrade using the six library.
Python 3 may, however unlikely, "die", but this and Google won't be the death of it.
the following url holds a good writeup about the intensions of developing grumpy
https://opensource.googleblog.com/2017/01/grumpy-go-running-...
Even some libraries only support Python 2.
Why can't we move on ;(
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.
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.
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/...
[1]: http://docs.python-guide.org/en/latest/starting/which-python...