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

271–280 of 463 posts

Re: Grumpy: Go running Python

#271

Post by xapata »

trotterdylan wrote: post #169
Walkman wrote: post #142

Earlier quoted context omitted.

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

You won't get exact compatibility, but a metaclass implementation would give almost all the features. I can't remember what exactly you give up, but I did that once and I lost some introspection friendliness.

Re: Grumpy: Go running Python

#272

Post by simonster »

lima wrote: post #210
jerf wrote: post #195

Earlier quoted context omitted.

The scientific community uses it as a tool to automate specification of tasks to be performed inside of C libraries. It's a case pjmlp may not have explicitly named, but it's of the same kind.

PyPy is making good progress at implementing and JITing numpy as native Python code.

They've been working on NumPyPy since at least 2011, and to my knowledge it's still not in serious use.

Re: Grumpy: Go running Python

#273

Post by mdaniel »

BuckRogers wrote: post #257
Pxtl wrote: post #251

I can't help but see this balkanization of Python as a sign that the core language is falling apart. How many interpreters are there now? And how many of them have even close to 100% compatibility with Python 2.7 or 3.N? Guido has lost control of the language, but has he's still officially the BDFL there's no real standardization body. His stubborn view on functional mechanisms have held the language back syntactical…

GVR, the PSF and the core dev team overestimated their influence. They still truly believe the majority will come around to Python3. I agree with your sentiments and balkanization is the right word. Guido won't even read these comments. He thinks it's all some unjust slander and nonsense that will be forgotten in 3 years. :) It is a good time to jump off the Python train in general, and I say that as someone invested…

> Here's to hoping Grumpy takes on a life of its own and is the new de facto Python.

I can appreciate you have that opinion, but I'll be livid if that's true - the last thing in the entire world I want is to do battle with dependencies and the very, very strict/opinionated Go build system.

If your idea is that all Py27 is just transpiled into Go and then jettisoned, that's fine, but keeping one foot in each world sounds terrible.

Re: Grumpy: Go running Python

#274

Post by weberc2 »

curtis wrote: post #117

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…

I don't know that it was made with assumption that everyone needs a better C, but certainly that many could benefit from it. I think they were largely correct--I certainly appreciate Go's simplicity and ease of use.

Re: Grumpy: Go running Python

#275

Post by kibwen »

derefr wrote: post #235
tedmielczarek wrote: post #193

Earlier 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…

> I kind of like the idea of having access to the Python library ecosystem from Go

I'd like to see an example of this, because from the blog post I get the impression that this mostly allows accessing the Go ecosystem from Python, rather than the other way around. For example, how would Python classes be handled from Go?

Re: Grumpy: Go running Python

#276

Post by vorg »

acd wrote: post #255

May I suggest GoPy as name

Maybe you don't like Grumpy as a name. I think it was named after NumPy (pr. ˈnʌmpaɪ) so I guess it's pronounced ˈgrʌmpaɪ rather than ˈgrʌmpi:

Around 2011 the beta releases of the static typing additions to Apache Groovy were called "grumpy" but the name was dropped after objections from the Grails crowd. I think the quality of the product is more important than the name, so Grumpy should do OK regardless if it's built and maintained properly.

Re: Grumpy: Go running Python

#277

Post by vram22 »

takeda wrote: post #228
vram22 wrote: post #111

Earlier quoted context omitted.

>Additionally, Go code runs inside an event loop, which enables excellent I/O performance without kernel context-switches Interesting, didn't know this (that Go code runs in an event loop). Is the reason something to do with goroutines and channels? something like, a routine gets info that data is available for it to read (on a channel, sent by another goroutine), via an event it receives? Also, can you explain this…

Since we also talking about Python. If you ever used AsyncIO you will see that programming in it is a bit different than you usually write code without it. Before you can call any coroutine you first need to start an event loop and schedule something in it. This essentially enables the language to schedule another async function each time you use await. Since Go by default always is async, before your main function i…

Interesting ...

Re: Grumpy: Go running Python

#278

Post by nine_k »

onalark wrote: post #162
genericpseudo wrote: post #149

Earlier quoted context omitted.

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 ref…

Having typed arrays without efficient functions over them would be rather pointless.

Re: Grumpy: Go running Python

#280

Post by frou_dh »

curtis wrote: post #266
dochtman wrote: post #182

Earlier quoted context omitted.

It seems likely to me that Rust is your better C++. I'm also quite positive that there is (more than) enough oxygen for Rust to succeed. As for D, I think it has numerous other issues, that don't apply to Rust.

The stuff I've done in C++ would have worked as well or better in a language with garbage collection. On the other hand if you want to write the next OS kernel, then you need a "better C++" that is designed to work without GC. In the latter case, I think there is no question that Rust is your best bet today. I'd like a programming language that is statically compiled, with good performance, garbage collection, and de…

> I'd like a programming language that is statically compiled, with good performance, garbage collection, and decent support for abstraction.

Well if you really are tired of "better C" (in varying guises) then pull the fire alarm and go off-piste with OCaml or Haskell

Post reply on HN