Make Python Compilable, convert to Python source to Go

[bookaa bookaa]

On Sunday, May 25, 2014 12:47:27 PM UTC+8, Chris Angelico wrote:
> On Sun, May 25, 2014 at 1:06 PM, bookaa wrote:
> 
> > This tool can be called 'Python to GoLang', which translate Python source to Golang source. And then you can compile the Go files to executable binary. (btw: Go is a new C-like compilable language, open source).
> >
> 
> Sounds like you're writing a Python implementation that uses a Go
> backend. As Pythons go, this is comparable to using Java, or Mono, or
> RPython, or C, or anything else. So there are two questions:
> 
> 1) How compatible is your Python-to-Golang converter with all the
> nuances of Python code? Does it work perfectly on any arbitrary Python
> script? And, what version of Python is it aimed at?

I try to support all Python syntax, any arbitray script. From the example
 attached,you can see I translate all import system libraries needed and 
produce up to 170000　lines of Go. Up to now, only support Python 2.7.6. 
Maybe I will work on Python 3 later.

> 2) What's performance like? Presumably significantly better than
> CPython, as that's what you're boasting here. Have you run a
> standardized benchmark? How do the numbers look?
 
I must admit that after automaticaly convert Python source to Go, compile 
to EXE, the running speed is just as before. For compatible reason, I must 
make it behave　just as it before, support any Python feathers. Take a 
example, if we find a function　call func1(2), I can not simply convert it 
to Go function call as func1_in_go(2), but　something like this: current_module_scope.GetAttributeString("func1").CallObject(2)
because func1 maybe overwrited.

I think the significance of Python to Go, is it give us opportunity to 
make Python project run fast. We may edit the output Go source. or We 
may add some Python decorator to tell the converter its safe to convert 
it in simple form.
 

> If the answer is "It'll work on anything, but it's only faster if you
> restrict yourself to a specific subset of Python syntax", that's still
> useful. But we'd need to see figures that tell us when it's worth
> adding a separate dependency and another translation layer (after all,
> every layer adds its own bug potential).
> 
> ChrisA

thanks, LiuTaoTao