Google 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 internally. It also doesn't run Python code directly, it trans-compiles Python to Go code, which wouldn't work for some workflows. For this to have any possibility of becoming another Python runtime, it would at the very minimum have to support every feature or have a real reason to not support the specific feature in Python 2.7.

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.

you're right,

the following url holds a good writeup about the intensions of developing grumpy

https://opensource.googleblog.com/2017/01/grumpy-go-running-...

i totally disagree with your view. Python 3 of today is fantastic and the community is fully behind it.

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!

I'm with you. Also, I don't see that Google is going to make a difference with packaging, they have very particular use cases.

Grumpy will primarily make a difference for people who think they're Google, I can't imagine it'll be widely adopted.

With due respect, if the community was fully behind Python 3, it wouldn't still be controversial. Clearly it still is.

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.

> With due respect, if the community was fully behind Python 3, it wouldn't still be controversial. Clearly it still is.

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

[1]: http://py3readiness.org

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.

I think the choice of title for HN is unfortunate: it implies (for me) some inside knowledge about what is (or will) happen to Python. Casual HN readers will see the death of Python as a done deal, whereas the truth is "the reports of [Python's death] are much exaggerated".

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

Ha, 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?

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

It's bad that the runtime is fragmented. Google will fix it by creating a new runtime

(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/...

I think the argument for runtime fragmentation and package fragmentation is a bit exaggerated. Most people use pip. Most people use CPython. People make tradeoffs when they need to use another interpreter for performance reasons [1], but CPython is the reference implementation. Just because alternative options exist for specific cases doesn't mean there's fragmentation in the ecosystem at large.

[1]: http://docs.python-guide.org/en/latest/starting/which-python...

this is all about confusion and fud, not grumpy of course, the way it's presented in this thread, sucks to be a n00b in 2017.

This is another python 2 fork that reading this reminded me of: https://github.com/naftaliharris/tauthon

Python's primary value is the ecosystem. With a general agreement to move to Python3, Google would just be handicapping themselves. An interoperable Py2/3 interpreter seems more likely.

Better come over to Perl before it's to late guys ;)

How do you explain the fact TensorFlow targets Python 3 for speed, features, etc.?

It's not true. TensorFlow also supports 2.7 first.

Most of their official examples do not work in Python 3. https://github.com/tensorflow/models