looping over lines of a file object does not translate correctly

Hi there! Cool project. I gave it a play with some simple example code and noticed that looping over the lines of an open file object does not translate properly yet, so I thought I would leave this bug report here.

def main():
	fh = open("file.txt")
	for line in fh:
		print(lin)
	fh.close()
  
	with open("file2.txt") as fh2:
		for line in fh2:
			print(line)

if __name__ == '__main__':
  main()

Currently translates to:

package main

import "fmt"

func main() {
	fh := open("file.txt")
	for _, line := range fh {
		fmt.Println(lin)
	}
	fh.close()
	func() {
		fh2 := open("file2.txt")
		defer func() {
			if err := fh2.Close(); err != nil {
				panic(err)
			}
		}()
		for _, line := range fh2 {
			fmt.Println(line)
		}
	}()
}

[nottheswimmer]

Does it know not to panic if the original python code used exception handling?

try/except is obviously tricky in Go – I do have a toy implementation of it which users recover (CTRL+F for “except” in the README) – and I’ll add a line to inform it to check for ErrUnexpectedEOF when there’s an except for EOFError for now – but, obviously this is far from how you’d want it done in Golang.

Trying to perform more specialized implementations of try/except handling actual error objects would be very nice although not easy… I’m open to hearing some ideas about how that might generalize. Maybe creating an anonymous error handling function with the except block and applying it to every error inside of the body with a panic? But then any functions would need to return errors instead of panicking which isn’t really a pattern you see in Python…

Is this idiom being used to ensure the generated code is using smaller scoping for the variables to avoid potential conflicts?

Yup. The code for handling scope in this library is very rough – the scope rules in Python and Go are super different and that is something I haven’t tackled head-on yet. I’ve considered doing a complete overhaul of this by augmenting the AST with the scope of all variables using something like https://github.com/kavigupta/ast_scope/ (I’ve checked it out – it’s good but incompatible license) or https://github.com/PyCQA/astroid (haven’t checked it out but it’s actively maintained and has a compatible license).

So, using hacks like this help get around complications that might arise with scope (especially when dealing with nesting, I do very little variable renaming presently) while keeping the code close to 1:1 with the original (a statement for a statement, an expression for an expression).

[justinfx]

Oh man. Sorry about the Println suggestion. Ignore me!

That new version of the line reading definitely looks like it covers all the issues. NIce one. Does it know not to panic if the original python code used exception handling?

Re:

if sc, line, err := bufio.NewReader(fh), "", *new(error); true { ... }

Is this idiom being used to ensure the generated code is using smaller scoping for the variables to avoid potential conflicts?