The blog post says that YouTube is the inspiration for this runtime, but does YouTube run on Grumpy yet?
YouTube does not run on Grumpy. There is a lot of work left to do before Grumpy can run a large existing codebase.
Grumpy: Go running Python
101–110 of 463 posts
Re: Grumpy: Go running Python
#102As someone who works on both python and go day to day, I find this to be quite interesting. Just tried this out on a reasonably complex project to see what it outputs. Looks like it only handles individual files and not any python imports in those files. So for now you have to manually convert each file in the project and put them into the correct location within the build/src/grumpy/lib directory to get your depende…
I hope this is a well thought out solution that can evolve into something great... and not just something built for a single purpose. I question the transpiler. I think I'd much rather prefer a solution like Jython.
I'm confused because Jython runs on the JVM, but Go is a compiled language. Can you clarify?
Re: Grumpy: Go running Python
#103Earlier 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.
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).
Re: Grumpy: Go running Python
#104Earlier quoted context omitted.
> 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…
> 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…
> > 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 ?
literal_eval could in principle be supported I think. name.__dict__[param] = value works as you'd expect:
$ make run
class A(object):
pass
a = A()
a.__dict__['foo'] = 'bar'
print a.foo
bar
Re: Grumpy: Go running Python
#105Earlier quoted context omitted.
> There are restrictions. I'll update the README to make note of them. Basically, exec and eval don't work. Since we don't use those in production code at Google, this seemed acceptable. I'm guessing pretty much the entire AST module is a no-go?
I think the CPython AST module is written as a C extension module so currently it's a no-go. I don't think there's a fundamental reason Grumpy couldn't run a pure Python AST module, though.
The ast module itself is in Python, but it imports the _ast module which is an extension module. This actually isn't that big of a deal, though, as the entire AST is defined in a DSL (see https://cpython-devguide.readthedocs.io/en/latest/compiler.h... for some details), so you just have to write some code to generate _ast in Python instead of C (which PyPy may have already done).
Re: Grumpy: Go running Python
#106Earlier 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.
Well, the difference here is that Google seems to be looking at Golang as the future for their internal tooling currently implemented in Python 2.x, instead of Python 3.x. I'm curious to know how much additional work might be necessary for this to support 3.x, but it doesn't sound like that's part of their use case.
Re: Grumpy: Go running Python
#107Earlier quoted context omitted.
> 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…
> 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.
Re: Grumpy: Go running Python
#108Earlier quoted context omitted.
It does not, yet. The standard library is very incomplete at this point.
I'm not particularly concerned about the standard library, but about the more dynamic features of the language. Not just exec/eval, but for example the complex dispatching logic behind magic methods, especially the various __getattr__, __getattribute__. They are where alternative runtime implementations usually stumble, as if they were an intrinsic bottleneck to Python runtime performance.
exec/eval do not work, but all of the other dispatching and magic methods are supposed to work exactly like CPython (and if they don't, it's a bug/not yet implemented).
Re: Grumpy: Go running Python
#109- 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,…
> Nobody uses that stuff in production code Nobody uses the features of Python which make it a dynamic language? Google must write some really weird Python if their compiler is that strict.
Their python is weird if it doesn't use eval?
Re: Grumpy: Go running Python
#110Earlier quoted context omitted.
> 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.
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).