Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grumpy: Go running Python

opensource.googleblog.com

Post reply on HN
Print view View original

431–440 of 463 posts

Re: Grumpy: Go running Python

#431

Post by BuckRogers »

statsmatscats wrote: post #423
BuckRogers wrote: post #409

Earlier quoted context omitted.

Citations needed for your assertion on each point being false. Grumpy proves Python2 is where the action is at. Everyone wanted a speed improvement with a new Python, that's the ultimate carrot.. instead Python3 was and still is in some ways slower than 2. Other than exec, eval and C-extensions, Python2 is valid Grumpy. You didn't provide any reasoning or proof that my points, which were just reiterated, were false.…

Lead on the project said he would like to support python 3 at some point.

That would be great. But the issue is really what do people do that have all this mass of Python2 source. The Python3 people are off doing what they want to do on that, which I consider the experimental branch. There's just so many new mistakes made with Python3 it's not a slam dunk for people to move to. At this point, it's become more of a social pressure / political thing (2020?) than a logical decision to move to 3. Something like Grumpy is definitely going to take the throne that Python3 abandoned.

Re: Grumpy: Go running Python

#432

Post by kevinmgranger »

teaearlgraycold wrote: post #420
porker wrote: post #384

Earlier quoted context omitted.

> His stubborn view on functional mechanisms Reference, for a non-Python dev who hasn't kept up with it?

Guido has said that he wishes Python didn't have lambdas. Also, map and reduce were removed from the standard global namespace and into the functools module.

Reduce was, map wasn't.

https://docs.python.org/3/library/functions.html#map

Re: Grumpy: Go running Python

#433

Post by kazinator »

fiddlerwoaroof wrote: post #224
Animats wrote: 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,…

> - 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, and Google apparently dumped it. Does it really imply many restrictions? Common Lisp, for exampl…

20 years only takes us back to 1997, several years after Common Lisp was finally standardized. The ancestral dialects of Common Lisp were compiled as far back as the early 60's.

Re: Grumpy: Go running Python

#434

Post by xordon »

wrsh07 wrote: post #177
curtis wrote: post #171

Earlier quoted context omitted.

For better or worse, I think Go sucked up a lot of the metaphorical oxygen for similar languages. Swift and Rust are in different niches and don't compete head to head with Go, so this isn't a real problem for them. What I've long wanted is a better C++ , not a better C. It would be hard for any such language to succeed today, because it will have to compete with Go, and Go has a fairly mature toolchain and widesprea…

For my money, a better C++ is in development: it's called C++20.

C++ with more stuff isn't the same as "better C++".

C++ has more features than any one person could ever need and it seems like the design philosophy is: anything that is possible in any language; should be added to C++. In reality it is a huge problem for productivity.

Re: Grumpy: Go running Python

#435

Post by tedmielczarek »

teddyh wrote: post #363
tedmielczarek wrote: post #202

Earlier quoted context omitted.

They tried that with CPython, it didn't work: https://www.python.org/dev/peps/pep-3146/

But it was no fault of Python: https://qinsb.blogspot.nl/2011/03/unladen-swallow-retrospect...

Interesting, I hadn't seen that post! I wonder if there are any posts that elaborate on the internal Google bits more. I'd love to know what "they found other ways to solve their performance problems" wound up meaning in practice.

Re: Grumpy: Go running Python

#436

Post by int_19h »

dismantlethesun wrote: post #377
int_19h wrote: post #356

Earlier quoted context omitted.

If you backport every new Python3 feature to Python2, it becomes Python3, by definition.

It could become Python 2.8, wherein the standard library has both the legacy versions and the new versions, and any cross-compatible syntax is allowed. This leaves us with more than 1 way to do things, like meta-class declaration. There's a lot in Python 3 where changes were made to the syntax for 'clarity', but those worts weren't removed for any technical reason but because of the thought that since backwards compa…

> It could become Python 2.8, wherein the standard library has both the legacy versions and the new versions, and any cross-compatible syntax is allowed.

So two `builtin` modules, then?

What if someone does `sys.modules['builtin']`? Or any other kind of explicit string-based lookup?

How does pickle figure out which types to instantiate? There'd be a lot of types with same qualified names but different implementations with this approach...

It feels like the only way this would work reliably, is if you completely isolate the Py2 and Py3 universes. So if you e.g. pickle from Py2 code, it only looks at modules and types that Py2 universe knows, and vice versa.

But then what happens when code using the old library interacts with the new one (e.g. tries to pass objects around)? If that is prohibited, then you effectively still have two different languages, just with a single shared implementation - but no ability to gradually replace bits and pieces of code, for example, which would seem to be the biggest motivation for such a thing.

Re: Grumpy: Go running Python

#438

Post by dsymonds »

masklinn wrote: post #381
dsymonds wrote: post #304

Earlier quoted context omitted.

Segmented stacks in Go went away in Go 1.3 ( https://golang.org/doc/go1.3#stacks ; June 2014). 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.

> The bigger one is the GC; the Go runtime needs to know which pointers it is responsible for freeing That is not the bigger issue, and AFAIK already handled for C types. The stack/calling conventions is the reason why cgo is "not go", cgo calls have significantly more overhead than just about every other FFI (the overhead of a cgo call is ~2 orders of magnitude more than a "native" go call, or was around the same ti…

The original question was about why C extensions are not supported by Go. It's not a matter of performance; it's a matter of correctness.

Re: Grumpy: Go running Python

#439

Post by fiddlerwoaroof »

kazinator wrote: post #433
fiddlerwoaroof wrote: post #224

Earlier quoted context omitted.

> - 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, and Google apparently dumped it. Does it really imply many restrictions? Common Lisp, for exampl…

20 years only takes us back to 1997, several years after Common Lisp was finally standardized. The ancestral dialects of Common Lisp were compiled as far back as the early 60's.

I didn't mean to imply that Lisp was only 20 years old or that common lisp was precisely 20 years old (I used the `~` to indicate that Common Lisp was approximately 20 years old), I just wasn't sure whether Lisp has always been a compiled language, so I restricted my claim to being a claim about Common Lisp and estimated its age conservatively.

Re: Grumpy: Go running Python

#440

Post by jwillp »

trotterdylan wrote: post #285
justinsaccount wrote: post #246

Earlier quoted context omitted.

> I'll update the README to make note of them. I managed to run into 2 trying to build a 5 line program :-) $ cat t.py; ./tools/grumpc t.py > t.go;go build t.go;echo '----';./t import sys print sys.stdin.readline() ---- AttributeError: 'module' object has no attribute 'stdin' $ $ cat t.py ;./tools/grumpc t.py c = {} top = sorted(c.items(), key=lambda (k,v): v) Traceback (most recent call last): File "./tools/grumpc",…

Ugh, sorry about that. There's a couple issues here: 1. Lambda tuple args are not yet supported -- I actually didn't know that was a thing :\ -- https://github.com/google/grumpy/issues/17 2. Even if that worked properly, sorted() is not yet implemented: https://github.com/google/grumpy/issues/16

sorted() is widely used, adding will extend coverage considerably.
Post reply on HN