Live data from Hacker News

Grumpy: Go running Python

opensource.googleblog.com

301–310 of 463 posts

Re: Grumpy: Go running Python

#301

Earlier quoted context omitted.

Given that there are only 7.5 billion humans on the planet, and that rather significantly fewer than 1 in 20 people are PyPy-using developers, perhaps those numbers should be taken with a grain of salt? The message I would take from those statistics is that needing a fresh download of Pypy is less common among 3.x users than among 2.7 users, who apparently needed to reinstall from the web at least a few times a day d…

> Given that there are only 7.5 billion humans on the planet, and that rather significantly fewer than 1 in 20 people are PyPy-using developers, perhaps those numbers should be taken with a grain of salt? Those are not downloads of PyPi, but of packages. It's not like "number of downloads == number of individual developers". Those are packages, including package updates. A single developer can download 50 deps across…

That response is talking about something else because your original comment accidentally said "PyPy", which is an implementation of Python, instead of "PyPI", the package repository.

Re: Grumpy: Go running Python

#302
post #262

Is this the final nail in the coffin for Python3? Seems like it. Who would use 3 if you could have CPython2 for existing code and write new code in Grumpy Python? This is the dream language for me. Python on the Go runtime.

Python 3 is a more modern, better language, that's why. Hopefully, grumpy will support it soon enough, though it's understandable that they started with 2.7 to support Google's huge older codebase.

That's a bit of hyperbole. Python3 is technical churn, not technical innovation. They just stirred the pot and added some features that have no barrier to being added to Python2 and were, with Naftali Harris' Python 2.8.

But the bigger problem other than lack of widescale user adoption is that the primary reason for Python3 (unicode) was botched. Go got this right, everything is a byte string and the assumed encoding is UTF8.

Re: Grumpy: Go running Python

#303
post #200

Earlier quoted context omitted.

That's top-down change from the PSF/core dev team and some major library developers added dual 2/3 support. The users never arrived and it'll be 10 years Python3 has been available next December. I'd like to unify Python again but we as users didn't break it either. 10 years any reasonable person in charge would hang it up or change course. Grumpy is pretty much what most everyone would actually want out of a new Pyt…

> some major library developers added dual 2/3 support > The users never arrived That's the way it used to be a few years ago - it changed a lot the last few years. Pretty much all libraries are ported and many new libraries are Python 3-only. asyncio is nice . All Python devs I personally know moved to Python 3. Porting is a lot less painful than it used to be.

Gevent is nice. AsyncIO is terrible[0].

[0]http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio...

Re: Grumpy: Go running Python

#304
post #51

Earlier quoted context omitted.

Does anyone know the technical reasons why C extensions are not (at least easily, apparently) supported by Go? Is it to do with Go's being a GC'd language? I would have thought that should not be a reason per se, since Python also has GC, but has plenty of extensions written in C. But I'm not a language internals expert. Also, further signs that GC may not be the reason, is that D also has GC, but can link to C libra…

It's because Go uses a different stack structure, called "segmented stacks", in order to enable cheap goroutines. Basically, Go stacks start tiny (8 KiB, as opposed to much larger C stacks), then it grows them in small segments. Additionally, Go code runs inside an event loop, which enables excellent I/O performance without kernel context-switches, and ordinary C function calls conflict with this event loop.

Segmented stacks in Go went away in Go 1.3 (https://golang.org/doc/go1.3#stacks; June 2014).

The alternate stack structure is indeed one issue. The bigger one is the GC, though; the Go runtime needs to know which pointers it is responsible for freeing, and which are the responsibility of the C code.

Re: Grumpy: Go running Python

#305

Earlier quoted context omitted.

The first stop is usually a CONTRIBUTING.md Here's theirs https://github.com/google/grumpy/blob/master/CONTRIBUTING.md There's not a ton there. The next place I'd go is open issues: https://github.com/google/grumpy/issues It looks like at the moment they're mostly random bug reports from people who have tried Grumpy since this announcement, rather than ones filed by people working on Grumpy since before it was made p…

That's super helpful; much appreciated!

No worries. Open source can be tricky to get into, but it's largely about just keeping at it: A story I like to tell is how my first ever PR to Rust was actually rejected based on a procedural issue. Now I'm on its core team. It might take you a while, but if you keep at it, I'm sure you'll figure it out.

Re: Grumpy: Go running Python

#306
post #229
post #6

It seems interesting but my concern is that it's just another Unladen Swallow.

To me it looks like Google essentially is moving everything to Go, and this project is to help with it. They port their python libraries so they can reference them from their Go code, and then module by module will rewrite it in pure Go.

>Google essentially is moving everything to Go ...[snip]... and then module by module will rewrite it in pure Go.

I can see this happening for some core modules sure, but I think you've underestimated the work required to convert the sheer amount of Python code at Google. There is a tool inside Google which graphs the number of lines of each language in Piper; I don't think I can quote numbers from my time there but it would be no small feat, even for Google.

Re: Grumpy: Go running Python

#307
post #46

For those who are interested, I've used grumpy to compile the following Python code and placed it at https://play.golang.org/p/YP1SP7WsdR . (Note the playground can't run this, it just had convenient formatting support for Go; the generated source wasn't 100% gofmt compliant.) class Test(object): def __init__(self, value): self.value = value def method(self): print(self.value) class Test2(Test): pass t = Test("hello"…

Interesting to note that `print()` is supported out of the box--no need to `from __future__ import print_function`.

That's a print statement with an expression surrounded by parentheses. You can try it yourself in a Python 2 interpreter.

Re: Grumpy: Go running Python

#308

Earlier quoted context omitted.

Python 2.7 is EOL in 2020. Make of that what you will :/

That means nothing. Python 3 was also expected to be mainstream by 2015, but it's nowhere near even 30% yet.

It's mainstream for new projects. Which is what was expected and aimed for.

Re: Grumpy: Go running Python

#309
post #235

Earlier quoted context omitted.

Given the failure of their unladen-swallow work to make it into CPython, I think Google is probably tired of trying to make Python faster. Some of their stated goals with Go were to be a faster, compiled Python, so this makes a lot of sense for their use case. They face the choice of fixing all their existing Python code to run in Python 3 (which won't make anything faster), or just porting everything to a different…

> I don't know that this makes sense for anyone but Google I'm not sure; as a Go developer, I kind of like the idea of having access to the Python library ecosystem from Go, without being forced to create an IPC bridge and building up the requisite release-management and deploy-time goop. Plus, I'm just not a Python developer; in the case where the only library that exists to do something is written in Python, I'd mu…

IIUC, it's not about accessing python libs from go. It's for accessing go libs from your python program and transpiling that python code to go source and compile it with go tool chains.

Eg: python code (from blog post)

  from __go__.net.http import ListenAndServe, RedirectHandler

  handler =  RedirectHandler('http://github.com/google/grumpy', 303)
  ListenAndServe('127.0.0.1:8080', handler)

Re: Grumpy: Go running Python

#310
post #200

Earlier quoted context omitted.

> some major library developers added dual 2/3 support > The users never arrived That's the way it used to be a few years ago - it changed a lot the last few years. Pretty much all libraries are ported and many new libraries are Python 3-only. asyncio is nice . All Python devs I personally know moved to Python 3. Porting is a lot less painful than it used to be.

Gevent is nice. AsyncIO is terrible[0]. [0] http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio...

It's actually ridiculously nice, especially with the new async/await constructs.
Post reply on HN