131–140 of 463 posts
- 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.
Grumpy doesn't even seem to try to implement that. That's a good thing. If you restrict Python a little, it's much easier to compile.
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).
Grumpy is pretty much what most everyone would actually want out of a new Python and may have arrived just in time.
One of my complaints about Go is that it seems to be designed with the (mistaken, in my opinion) notion that what we really need is just a better C. One way to leverage C's widespread availability and high-performance while side-stepping some of its deficiencies was simply to use it as a target for a different language. The Cfront C++ compiler which generated C code is probably the most famous example, but I recall t…
It was designed with the notion that all some people really need is just a better C.
For other people there's Swift, Rust, etc.
Haha, now that's what I call an interesting project. The biggest surprise for me is that the Go runtime would be a good fit for Python, performance wise, considering the very different object and dispatch model. The post also mentions runtime reflection, which used to be painfully slow last time I used it. (Go 1.5, i think). Has this improved in the latest releases?
* It seems like writing a translator to deal with all the use cases is so much more work and risky than iteratively rewriting portions (in whatever faster more concurrent language) and using some form microservice/process message passing to communicate with legacy pieces.
* Love to know how they compose async operations currently? Is it some sort of object (e.g. Futures, promises, observables, etc)? Is Grumpy going to have some sort of language difference (to Python) to compose async stuff (e.g. async and await)?
Of course being biased towards the JVM (since I know it so well) they could get really fast concurrency if they want with Jython today. Most of the Python tools already work with Jython (assuming 2.7).
With Jython you could always drop down into Java (or any other JVM lang) if you need more speed as well C for cpython (or even C from Java). It is unclear what you do with Grumpy with performance critical code. Can you interface with Go code or is the plan C?
Earlier quoted context omitted.
Out of curiosity, what C extensions does YouTube use? If this is good enough to run YouTube's python code already it's honestly super impressive. Well done.
To be clear, Grumpy cannot yet run YouTube's Python codebase. There's still a lot of work to do on the standard library. There are a handful of C extensions for JSON, protobufs, etc that YouTube uses, but mostly they're small utility functions written by us to optimize particularly hot code paths.
(If the former, you could just update the code to use the standard Go JSON/etc packages..)
The main reason I moved from coding in Python to Go as my main language many years back is because concurrency was such a pain in standard Python (the other was compile time error checking). It's interesting to see the same pain has now made caused the runtime itself to be implemented in Go. It's a pity C extensions (often used in scientific computing) are not supported but Go does have support via CGO, so maybe some…
I never saw Python as anything more than a scripting language to portably automate tasks across UNIX and Windows environment, even back in the Zope days. My experience with Tcl teached me to stay away from languages that don't have either a JIT or AOT compiler on their reference implementation.
That looks like a super interesting runtime. Seems to target 2.7 only, I hope they're open to supporting 3.x as well.