gen: support for channels

[phil-mansfield]

Channel support is probably a ways off, but I guess it's good to make an explicit issue of it ;)

Building the package

package channel

func Channel() chan int {
    return make(chan int)
}

fails when built with go build channel.go && gopy gen. The following message is generated:

panic: unhandled obj [*types.Var]
type [&types.Chan{dir:0, elem:(*types.Basic)(0x53fac0)}]

goroutine 1 [running]:
github.com/go-python/gopy/bind.(*symtab).addType(0x8205d33c0, 0x8820778b78, 0x820623db0, 0x8820778b18, 0x8205d2fc0)
    /Users/phil/code/go/src/github.com/go-python/gopy/bind/symtab.go:447 +0x522
github.com/go-python/gopy/bind.(*symtab).processTuple(0x8205d33c0, 0x8205d2fe0)
    /Users/phil/code/go/src/github.com/go-python/gopy/bind/symtab.go:349 +0x149
github.com/go-python/gopy/bind.(*symtab).addSymbol(0x8205d33c0, 0x8820778408, 0x820623d10)
    /Users/phil/code/go/src/github.com/go-python/gopy/bind/symtab.go:330 +0xd0a
github.com/go-python/gopy/bind.(*Package).process(0x82064af00, 0x0, 0x0)
    /Users/phil/code/go/src/github.com/go-python/gopy/bind/package.go:179 +0x26dd
github.com/go-python/gopy/bind.NewPackage(0x820623c70, 0x820663880, 0x16, 0x0, 0x0)
    /Users/phil/code/go/src/github.com/go-python/gopy/bind/package.go:44 +0x390
main.newPackageFrom(0x8205ea0a0, 0x1, 0x1, 0x82064adc0, 0x820664000, 0x8205ea0a0, 0x0, 0x0)
    /Users/phil/code/go/src/github.com/go-python/gopy/gen.go:209 +0x3bf
main.newPackage(0x7fff5fbffa41, 0x1, 0x8205d0104, 0x0, 0x0)
    /Users/phil/code/go/src/github.com/go-python/gopy/gen.go:179 +0x638
main.gopyRunCmdGen(0x820634a20, 0x8205cc260, 0x1, 0x1, 0x0, 0x0)
    /Users/phil/code/go/src/github.com/go-python/gopy/cmd_gen.go:75 +0x588
github.com/gonuts/commander.(*Command).Dispatch(0x820634a20, 0x8205cc260, 0x1, 0x1, 0x0, 0x0)
    /Users/phil/code/go/src/github.com/gonuts/commander/commands.go:221 +0x7e2
github.com/gonuts/commander.(*Command).Dispatch(0x820634c60, 0x8205cc250, 0x2, 0x2, 0x0, 0x0)
    /Users/phil/code/go/src/github.com/gonuts/commander/commands.go:187 +0x1f9
main.main()
    /Users/phil/code/go/src/github.com/go-python/gopy/main.go:42 +0x1fe

One potential way to handle this would be to equate channels and multiprocessing.Connection objects. When a channel is returned by a Go function, gopy calls multiprocessing.Pipe, and passes one Connection to a new listening thread and returns the other to the calling process. When the listening thread receives a value through its Connection, it calls a Go function that passes the value to the equivalent underlying channel.

The same strategy could be used in the other direction for passing a channel/Connection to a Go function from Python.

It might also make sense to create some class class ChanConnection(multiprocessing.Connection) which stores an explicit reference to the underlying channel, so that in the case where a Python routine passes a channel created in Go back to another Go routine, values passed through it don't need to pass back and forth through Python.

[sbinet]

naively, I was about to model channels as python's generators (which are IIRC coroutines) or like a threading.SomethingObject.

at first, I think it would be better to model them as completely opaque boxes which can be passed around and given back to a Go-backed function or method but never interact with them (and thus, possibly block) from vanilla python.

but I'll keep using multiprocessing in the back of my mind (and wouldn't be against a PR to review :P)

[phil-mansfield]

I agree an opaque representation seems like the safest bet for now. Plus, my guess would be that most functions that return channels return sending channels instead of receiving ones, so if the user really needed to, they could write a wrapper with a Send() method.

It'll be a little while before I could make sizable contributions. I've been pretty swamped with my own projects, and still have a number of 80%-finished potential gonum contributions I've been meaning to make for a while now. (Still, it would be a good excuse to refresh my CPython skills!)

[rcoreilly]

still not supported in new version...