I'd love something like this for JavaScript
Grumpy: Go running Python
161–170 of 463 posts
Re: Grumpy: Go running Python
#162Earlier quoted context omitted.
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).
NumPy is a library that provides typed multidimensional arrays and functions that run atop them. It does provide a built-in LAPACK/BLAS or can link externally to LAPACK/BLAS, but that's a side effect of providing typed arrays and is nowhere near the central purpose of the library.
Also, NumPy is implemented completely in C and Python, and makes extensive use of CPython extension hooks and knowledge of the CPython reference counting implementation, which is part of the reason why it is so hard to port to other implementations of Python.
Re: Grumpy: Go running Python
#163Earlier 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…
Is there not a single namedtuple in the entire Google codebase? That's strange :o
Are namedtuples that popular? They always felt awkward to me. If some temp variable with multiple values inside a loop, I either use normal tuple or a dict. If passing data around a dict or a real class. I never got the huge win from namedtuple?
Re: Grumpy: Go running Python
#164This seems like an odd engineering choice. Presumably the effort to create a python->go translator would be non-trivial. Why not just start rewriting components into Go, and migrating them out of Python, leaving python as essentially the presentation layer at most?
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 don't know PHP, but in the case of Python you will spend the next ten years ironing out subtle incompatibilities between CPython and this new thing.
Added up, it is easily more than 30s per line.
Re: Grumpy: Go running Python
#165It seems interesting but my concern is that it's just another Unladen Swallow.
There's no guarantee that it will succeed, but the fact that they're willing to sacrifice some considerable degree of compatibility to achieve other important goals may make the project a lot easier to pull off. I still think Unladen Swallow should have been based on V8, but as I recall that project had very strict compatibility goals that would have made a V8-based implementation impossible.
Even ignoring the extension-compatibility goal, at the time Unladen Swallow began, V8 was nothing more than an AST-based JITing interpreter, hence there were far fewer generally applicable parts of the code compared with today.
Re: Grumpy: Go running Python
#166How does this compare to Jython? The blog post says they looked at alternative runtimes but didn't like that they had tradeoffs (implying that Grumpy has no tradeoffs??). But Jython has been around for quite a while and also has no GIL: http://www.jython.org/jythonbook/en/1.0/Concurrency.html It can also handle Python's dynamic aspects.
Every time I've tried to use Jython, I've found it won't work with pre-existing code all that well. In part it has exposed CPython "implementation quirks" that people were wittingly or otherwise taking advantage of. In other cases there doesn't seem to be obvious reasons for the differences and has required special-casing the python code to handle it. It has been great with code written from scratch, specifically for…
That sounds like the kind of issue you'd have with any reimplementation of CPython though. It sounds like Grumpy doesn't support quite a few things, so I still wonder how they compare and why developing a new runtime was considered easier than reusing Jython.
Re: Grumpy: Go running Python
#167I'm a bit disappointed that the blog post doesn't explain why the authors didn't choose PyPy instead.
> These efforts have borne a lot of fruit over the years, but we always run up against the same issue: it's very difficult to make concurrent workloads perform well on CPython.
> To solve this problem, we investigated a number of other Python runtimes. Each had trade-offs and none solved the concurrency problem without introducing other issues.
Re: Grumpy: Go running Python
#168I'm curious to why they started this project when there already is low hanging fruit that can speed up Python (e.g. pypy). What makes this better other than to satisfy the inner go-fanboy?
Because they want to get off of Python completely, and forever. They're not looking for speed, they're looking to ditch the liability of supporting Python and its ecosystem.
Re: Grumpy: Go running Python
#169Earlier 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…
Is there not a single namedtuple in the entire Google codebase? That's strange :o
Heh, I came across the namedtuple exec thing the other day when I was trying to get the collections module working :\
namedtuple will have to be implemented differently. I think it can be accomplished by defining the class with type()? Maybe with a metaclass...
Re: Grumpy: Go running Python
#170- 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,…
No support for 3 makes sense. This is all about building an off-ramp to put Python behind them.