Live data from Hacker News

Grumpy: Go running Python

opensource.googleblog.com

121–130 of 463 posts

Re: Grumpy: Go running Python

#121
post #37

Earlier quoted context omitted.

cpython is the reference implementation, so it makes sense that it's; A) Not well optimised. B) Touting features before the spec/standard. EDIT: people really dislike that I said this, and I'm having trouble finding my original citation- it was on one of the many python books I own. Most likely "Learn Python The Hard Way" but I'll dig out the exact chapter where they compare pypy to cpython and mention that because c…

It makes sense that the official, primary and by far most popular implementation of one of the most used languages in existance is not well optimized? (edit: I'm just being polemic about your statement here. CPython is reasonably optimized within the constraints it currently has).

It only makes sense because it's python. A language where style is part of the syntax, and readability is one of the things that many libraries focus on , the so called being "pythonic".

It makes sense that the reference implementation mirrors the same patterns than the language itself.

Re: Grumpy: Go running Python

#123

Earlier quoted context omitted.

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?

Jython is a python interpreter written in Java. Grumpy is a python transpiler that converts python to navtive go object code.

Edited to add: The difference is that Jython doesn't covert python to JVM bytecode.

Re: Grumpy: Go running Python

#124
post #14

Earlier quoted context omitted.

Ask yourself how much Python code you think Google has. Then multiply it by some large single-digit number, minimum. Then compare the effort of spending 30 seconds per line on that code vs. writing a new Python interpreter/compiler/runtime, especially when you can trivially get people who are capable of doing that. There's a reason why the large companies often end up working on new runtimes/interpreters/compilers li…

I wouldn't think that a tool for transpiling Python to Go would be harder than creating a whole new runtime. Most of the work is already done; you can get the compiled ASTs directly out of Python itself. Of course, if it started out as a "this seems like a cool project", that skews the "a is more efficient than b" ratio significantly.

I mean, you can get something out of transpilers--not typically maintainable code.

Re: Grumpy: Go running Python

#125

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

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

Re: Grumpy: Go running Python

#126
post #35

How does Grumpy handle Decimal in Python? As far as I am aware there isn't an equivalent in Go.

The decimal module in Python 2.7 is implemented in pure Python: https://github.com/python/cpython/blob/2.7/Lib/decimal.py (in Python 3 there is an accelerated extension module that's used when available, falling back on the pure Python version otherwise).

Re: Grumpy: Go running Python

#127
post #121

Earlier quoted context omitted.

It makes sense that the official, primary and by far most popular implementation of one of the most used languages in existance is not well optimized? (edit: I'm just being polemic about your statement here. CPython is reasonably optimized within the constraints it currently has).

It only makes sense because it's python. A language where style is part of the syntax, and readability is one of the things that many libraries focus on , the so called being "pythonic". It makes sense that the reference implementation mirrors the same patterns than the language itself.

Someone else already posted this link: https://www.youtube.com/watch?v=qCGofLIzX6g&list=PLRdS-n5seL...

It explains why CPython can't improve on many things.

Re: Grumpy: Go running Python

#128

Very interesting project and technical solution. Is this in use at Google? The described example problem is Youtube with millions of requests per second, but the post doesn't say if it Grumpy was put in production (and what performance gains were then achieved).

As has been said by others, Grumpy is not used in production at Google currently. There's still a lot of work to do -- especially on the standard library -- to support large real world codebases.

Re: Grumpy: Go running Python

#129
post #66
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,…

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

>Nobody uses the features of Python which make it a dynamic language?

Python has TONS of dynamicity besides those (eval and co), who are seldom used by anyone anyway....

If you think eval is what makes Python dynamic you're doing it wrong...

Re: Grumpy: Go running Python

#130
post #40
post #4

I wonder why the Grumpy Fibonacci is so much slower than CPython for 1 thread. Seems weird given Grumpy is compiled.

Guido insists that single threaded performance of Python has the highest priority - http://www.artima.com/weblogs/viewpost.jsp?thread=214235 I am not sure, any implementation of Python will beat the single threaded performance of Cpython..

Multiple ones already do.
Post reply on HN