Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grumpy: Go running Python

opensource.googleblog.com

Post reply on HN
Print view View original

141–150 of 463 posts

Re: Grumpy: Go running Python

#141

Post by spanishgum »

cdelsolar wrote: post #110
BuckRogers wrote: post #103

Earlier quoted context omitted.

Python3 was never the future of Python. It never got over the hump all new languages need to if attempting to reach relevance. It's likely code using lots of C-extensions will continue with CPython2 and new code will be written in Grumpy (pure Python2).

That is pretty ridiculous. Pretty much all major libraries are Python 3 compatible and everyone is writing Python 3 (or should be). (Yes, I'm still on Python 2 but moving soon).

My python course at uni focused on python3. We talked about differences and toyed with both interpreters, but ultimately wrote all projects and assignments in 3. I'm sure this is the case for students at other schools too.

Re: Grumpy: Go running Python

#142

Post by Walkman »

trotterdylan wrote: post #61
Animats wrote: post #48

- Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. - It's a hard-code compiler, not an interpreter written in Go. That implies some restrictions, but the documentation doesn't say much about what they are. PyPy jumps through hoops to make all of Python's self modification at run-time features work, complicating PyPy enormously. Nobody uses that stuff in production code,…

> Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. Basically, we needed to support a large existing Python 2.7 codebase. See discussion here: https://github.com/google/grumpy/issues/1 > It's a hard-code compiler, not an interpreter written in Go. That implies some restrictions, but the documentation doesn't say much about what they are. PyPy jumps through hoops to make a…

Is there not a single namedtuple in the entire Google codebase? That's strange :o

Re: Grumpy: Go running Python

#143

Post by weberc2 »

I tried a simple `http.Get()` example, but the resultant `Response` object appears to not allow access to any of the struct fields as attributes. How does one access a Go object's fields from Python? For example, I want to `io.Copy(os.Stdout, rsp.Body)`.

Re: Grumpy: Go running Python

#145

Post by shanemhansen »

quotemstr wrote: post #91
poooogles wrote: post #59

Earlier quoted context omitted.

>- Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. Python 2.7 is what's running at Google. Not really surprising they're looking at this considering the fast approaching end of (core dev) support for Python 2.7. Write an interpreter in another language and programatically port modules to Go. Seems pretty sensible to me.

> Python 2.7 is what's running at Google. Not really surprising they're looking at this considering the fast approaching end of (core dev) support for Python 2.7. I'd prefer that all new Python tools that need to support 2.x also support 3.x. It's an additional development cost, but IMHO, a worthwhile investment in the future.

While python2 may be the past, I think that for many python3 is not the future.

Re: Grumpy: Go running Python

#146

Post by zardeh »

poooogles wrote: post #81
zardeh wrote: post #70

Earlier quoted context omitted.

Pypy still has a GIL. GIL-free seems to be one of the explicit goals of this project.

>Pypy still has a GIL. Not strictly true, http://doc.pypy.org/en/latest/stm.html . In general for the main project however, this is true.

Pypy still has a gil. Pypy is experimenting with non-GILed versions, and in fact there are people actively working to remove the GIL from pypy. But the same can be said of cpython (the gilectomy), and yet I don't think that you'd say "not strictly true" to "cpython still has a GIL".

Re: Grumpy: Go running Python

#147

Post by int_19h »

BuckRogers wrote: post #97

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.

Everyone who likes the numerous new language features, or new syntax for old features, in Python 3?

Re: Grumpy: Go running Python

#148

Post by dbaupp »

coldtea wrote: post #125
cdelsolar wrote: post #110

Earlier quoted context omitted.

That is pretty ridiculous. Pretty much all major libraries are Python 3 compatible and everyone is writing Python 3 (or should be). (Yes, I'm still on Python 2 but moving soon).

> and everyone is writing Python 3 (or should be) You'd be surprised. If anything, the numbers show the opposite. The vast majority of Python codebases, legacy or new, are 2.7 or older.

Which numbers? People keep saying things like that, but things like the Python 3 Wall of Superpowers https://python3wos.appspot.com/ don't seem to support it. Do you have something more concrete?

Re: Grumpy: Go running Python

#149

Post by genericpseudo »

ehsankia wrote: post #107
throwathrowaway wrote: post #83

Earlier quoted context omitted.

> Basically, exec and eval don't work. Since we don't use those in production code at Google, this seemed acceptable. What about stuff like literal_eval? Or even just monkeypatching with name.__dict__[param] = value ? > It does fine grained locking. Mutable data structures like lists and dicts do their own locking. Incidentally, this is one reason why supporting C extensions would be complicated. Would there be a suc…

Hmm, numpy isn't pure python, is it? If I read correctly this only works with pure python.

By volume numpy is mostly assembler written to the Fortran ABI (it's a LAPACK/BLAS-etc wrapper).

Re: Grumpy: Go running Python

#150

Post by statsmatscats »

trotterdylan wrote: post #140
scrollaway wrote: post #10

That looks like a super interesting runtime. Seems to target 2.7 only, I hope they're open to supporting 3.x as well.

I'd like to support 3.x at some point. See https://github.com/google/grumpy/issues/1

Have you thought about using type hints to help type inference?

Some work on that is discussed here. I would love a dropbox google colab (though also targeting 3.x :) )

https://github.com/python/mypy/issues/1862

Post reply on HN