Goimports will scrub unneeded imports. On Sun, Oct 7, 2018 at 4:50 AM Eric Raymond <e...@thyrsus.com> wrote:
> I am pleased to announce the release of pytogo 1.2. > > https://gitlab.com/esr/pytogo > > New features in this release: > > * PEP484 type hints are now converted into Go type signatures. > * Without PEP484 hints, return types of functions are now sometimes > deduced. > * Docstrings are moved to the godoc-preferred position above the > signature. > * Python math and cmath library functions are mapped over. > * Python shebang lines are recognized and converted to "package main". > * Map variadic function signatures to use "..." > * Import translation. > > Of these, the most interesting to go-nuts is almost certainly the PEP484 > support. It means that function signatures can be type-annotated in context > in Python before it is translated, substantially reducing the among of > hand-fixing required in the generated Go code. > > While this is still not a perfect, fire-and-forget translator - and never > will be - the ratio of output quality over LOC is, I feel, nothing short of > astonishing. We get what Michael Ellis described as "a good first draft" > from just just 594 lines of Python, much of that rule tables rather than > code! This demonstrates very concretely that the semantic gap between > Python and Go is narrow. > > The algorithm used for import translation is, though naive, surprisingly > effective. Python "import foo" is moved straight to Go `import "foo"` > (actually spans of them are grouped as is idiomatic in Go) except that > there is a table of special cases that should be dropped or translated. > So, for example, "import sys" is dropped (the portable stuff in it is in Go > os package) but "cmath" is mapped to "math/cmplx". Because Go throws errors > on unrecognized or unneeded imports, cleanup of an import section after > translation is fast and easy. > > This program will undoubtedly continue to gain capability, simply because > the overhead of adding new rules (such as new standard library module > mappings) is very low and testing them is easy. One current development > focus is better translation of "in" expressions outside for loops. It is > also very likely that the next release will translate some module-level > assignments in Python to Go var and const declarations. > > Sometimes minimum-effort, kludgy, brute-force-ish approaches work very > well. Python-to-idiomatic-Go translation seems to be one of them. > > Not losing sight of the goal despite this yak-shaving. The reposurgeon > translation is at 35% and my translation speed is up to more than 400 LOC > per day, easily doubling what I was doing before. It would be faster still > if I weren't writing a lot of unit tests that weren't there in the Python, > and I expect it to continue to rise. I plan to ship my experience report > on the translation to go-nuts at somewhere around 70%. It will be meaty. > > > > > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
