Earlier quoted context omitted.
Given that there are only 7.5 billion humans on the planet, and that rather significantly fewer than 1 in 20 people are PyPy-using developers, perhaps those numbers should be taken with a grain of salt? The message I would take from those statistics is that needing a fresh download of Pypy is less common among 3.x users than among 2.7 users, who apparently needed to reinstall from the web at least a few times a day d…
> Given that there are only 7.5 billion humans on the planet, and that rather significantly fewer than 1 in 20 people are PyPy-using developers, perhaps those numbers should be taken with a grain of salt? Those are not downloads of PyPi, but of packages. It's not like "number of downloads == number of individual developers". Those are packages, including package updates. A single developer can download 50 deps across…
Grumpy: Go running Python
301–310 of 463 posts
Re: Grumpy: Go running Python
#302Is 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.
Python 3 is a more modern, better language, that's why. Hopefully, grumpy will support it soon enough, though it's understandable that they started with 2.7 to support Google's huge older codebase.
But the bigger problem other than lack of widescale user adoption is that the primary reason for Python3 (unicode) was botched. Go got this right, everything is a byte string and the assumed encoding is UTF8.
Re: Grumpy: Go running Python
#303Earlier quoted context omitted.
That's top-down change from the PSF/core dev team and some major library developers added dual 2/3 support. The users never arrived and it'll be 10 years Python3 has been available next December. I'd like to unify Python again but we as users didn't break it either. 10 years any reasonable person in charge would hang it up or change course. Grumpy is pretty much what most everyone would actually want out of a new Pyt…
> some major library developers added dual 2/3 support > The users never arrived That's the way it used to be a few years ago - it changed a lot the last few years. Pretty much all libraries are ported and many new libraries are Python 3-only. asyncio is nice . All Python devs I personally know moved to Python 3. Porting is a lot less painful than it used to be.
[0]http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio...
Re: Grumpy: Go running Python
#304Earlier quoted context omitted.
Does anyone know the technical reasons why C extensions are not (at least easily, apparently) supported by Go? Is it to do with Go's being a GC'd language? I would have thought that should not be a reason per se, since Python also has GC, but has plenty of extensions written in C. But I'm not a language internals expert. Also, further signs that GC may not be the reason, is that D also has GC, but can link to C libra…
It's because Go uses a different stack structure, called "segmented stacks", in order to enable cheap goroutines. Basically, Go stacks start tiny (8 KiB, as opposed to much larger C stacks), then it grows them in small segments. Additionally, Go code runs inside an event loop, which enables excellent I/O performance without kernel context-switches, and ordinary C function calls conflict with this event loop.
The alternate stack structure is indeed one issue. The bigger one is the GC, though; the Go runtime needs to know which pointers it is responsible for freeing, and which are the responsibility of the C code.
Re: Grumpy: Go running Python
#305Earlier quoted context omitted.
The first stop is usually a CONTRIBUTING.md Here's theirs https://github.com/google/grumpy/blob/master/CONTRIBUTING.md There's not a ton there. The next place I'd go is open issues: https://github.com/google/grumpy/issues It looks like at the moment they're mostly random bug reports from people who have tried Grumpy since this announcement, rather than ones filed by people working on Grumpy since before it was made p…
That's super helpful; much appreciated!
Re: Grumpy: Go running Python
#306It seems interesting but my concern is that it's just another Unladen Swallow.
To me it looks like Google essentially is moving everything to Go, and this project is to help with it. They port their python libraries so they can reference them from their Go code, and then module by module will rewrite it in pure Go.
I can see this happening for some core modules sure, but I think you've underestimated the work required to convert the sheer amount of Python code at Google. There is a tool inside Google which graphs the number of lines of each language in Piper; I don't think I can quote numbers from my time there but it would be no small feat, even for Google.
Re: Grumpy: Go running Python
#307For those who are interested, I've used grumpy to compile the following Python code and placed it at https://play.golang.org/p/YP1SP7WsdR . (Note the playground can't run this, it just had convenient formatting support for Go; the generated source wasn't 100% gofmt compliant.) class Test(object): def __init__(self, value): self.value = value def method(self): print(self.value) class Test2(Test): pass t = Test("hello"…
Interesting to note that `print()` is supported out of the box--no need to `from __future__ import print_function`.
Re: Grumpy: Go running Python
#308Re: Grumpy: Go running Python
#309Earlier quoted context omitted.
Given the failure of their unladen-swallow work to make it into CPython, I think Google is probably tired of trying to make Python faster. Some of their stated goals with Go were to be a faster, compiled Python, so this makes a lot of sense for their use case. They face the choice of fixing all their existing Python code to run in Python 3 (which won't make anything faster), or just porting everything to a different…
> I don't know that this makes sense for anyone but Google I'm not sure; as a Go developer, I kind of like the idea of having access to the Python library ecosystem from Go, without being forced to create an IPC bridge and building up the requisite release-management and deploy-time goop. Plus, I'm just not a Python developer; in the case where the only library that exists to do something is written in Python, I'd mu…
Eg: python code (from blog post)
from __go__.net.http import ListenAndServe, RedirectHandler
handler = RedirectHandler('http://github.com/google/grumpy', 303)
ListenAndServe('127.0.0.1:8080', handler)Re: Grumpy: Go running Python
#310Earlier quoted context omitted.
> some major library developers added dual 2/3 support > The users never arrived That's the way it used to be a few years ago - it changed a lot the last few years. Pretty much all libraries are ported and many new libraries are Python 3-only. asyncio is nice . All Python devs I personally know moved to Python 3. Porting is a lot less painful than it used to be.
Gevent is nice. AsyncIO is terrible[0]. [0] http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio...