Hacker News Reader

Comment by jerf | Hacker News Reader

For 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")

    t.method()

Pythonistas, note I had to have "class Test(object):" and not just "class Test:". The former compiled successfully into a Go program but that program then failed at runtime with "TypeError: class must have base classes".

View on HN

Thanks for trying it out!

Yeah, Grumpy does not currently support old-style classes. Since all of our code internally requires new-style classes, this was not a high priority feature. It is something that we'll get to.

I did not mean that as a complaint against your very young codebase, I meant that as a defense against Python people complaining about my code. :)

I don't think they'd do that. All Python 2 code I've seen uses `class Foo(object)`, at least since 2.2 came out.

That's fascinating. It's creating run-time data structures similar to CPython's for data, and manipulating them with very general code. There seems to be a type comparable to Python's internal CObject, and it's used for most (all?) data. It's not generating Go that looks anything like human-written Go. There's no sign of type inference, although it's hard to tell from such a simple example. It's a lot like a Python run time environment, where everything is a CObject. Still, once you can do that, you can start optimizing, such as inferring that something is an integer and using ordinary Go arithmetic types.

All that stuff with "switch" seems to be to handle Python exceptions in a language that doesn't have exceptions. Maybe later, analysis can tell that some function can't raise an exception, and translated calls for such functions can be simpler.

Are Go's integers unbounded? If not, proving the value never exceeds the range to silent convert essentially a BigInteger into an int might be hard.

Go tends to use machine sizes like C, but this implementation appears to properly handle it. The following Python code has identical output for me under Python and grumpy:

    two_32 = 4294967296
    print(two_32 * two_32)
    print(type(two_32 * two_32))

And I tested some other things I won't burden HN with, but promotion is implemented, yes.

> Still, once you can do that, you can start optimizing, such as inferring that something is an integer and using ordinary Go arithmetic types.

I was hoping for something more aggressive even, like compiling Python classes to Go structs so long as the program doesn't need the dynamic behavior. Alternatively, Grumpy could support declaring native Go types via some sort of pragma or a new `struct` keyword or some such, which would be treated like a normal Go object (rather than defining your Go objects in a separate Go package).

I'd expect to see that in time. If you analyze the whole program to find all the fields of an object and verify the absence of code which dynamically adds a field, you can then make it a struct of "CObject" like entries. Then, try type inference on the fields. Some will clearly be integers, booleans, floats, or strings. Those can be represented with type-specific representations.

If you can identify the built-in types, that's most of the potential win; you get to do hardware arithmetic. If you represent integers as 64 bits and check for overflow, you probably don't need bignum promotion outside of crypto code.

Interesting to note that `print()` is supported out of the box--no need to `from __future__ import print_function`.

That's a print statement with an expression surrounded by parentheses. You can try it yourself in a Python 2 interpreter.

Sure, but that works without from `__future__ import print_function` in Python2 as well.

But it gives different output; the print() prints a tuple whereas the function print() prints a newline.

Also compare print(1) and print(1,2) with and without the __future__ import.

Oh, weird. I could have sworn I've seen errors for using parens with `print` in Python 2...

Reply on news.ycombinator.com