support for kwargs calls

[sbinet]

gopy should perhaps generate code with support for kwargs.

consider:

package pkg
func Hello(arg1, arg2 string) string {...}

should be callable from python like so:

import pkg
pkg.Hello("1","2")
pkg.Hello(arg1="1", arg2="2")

[phil-mansfield]

I like this idea, but it's not obvious to me that this is the correct approach. There are three issues that I have with it:

1. Unless there is an annotation in the Go code (or some wrapper type exported by gopy), there's no way for the Go code to specify what it intends the default arguments to be. gopy could always supply the zero value by default, but it'll often be the case that this is not a useful default value to have, meaning the user would have to supply those values anyway. E.g. if I defined def vector_deriv(xs, ys, order=4) in Python, most people probably wouldn't bother changing the kwarg, but if I defined it def vector_deriv(xs, ys, order=0), everyone would always have to set it anyway.
2. Unless there is an annotation in the Go code which dictates which arguments are and are not kwargs, all the arguments would be kwargs by default. This means that a programmer who types in the wrong number of arguments in Python won't receive a runtime error because of it.
3. Most Go code that I see in the wild which requires options supplies them in the form of

type Options struct {
    opt1, opt2, opt3 string
}

func F(arg1, arg2 string, opts *Options)

without annotations, Pythonizing this code would still have to be done by hand (either directly in the CPython, or with a Python wrapper function).

That all said, I'm not sure that annotations are the correct approach either: I feel like the intention is that someone should be able to run gopy on, say, github.com/gonum/matrix/mat64 without having to edit the Go source. (That's not to say that I think it should be doable without editing something, just not the input files.)

[sbinet]

you're correct: I wasn't very clear.

my intention was always to have (with the same definition than in the issue):

import pkg
pkg.Hello("1","2")  # OK
pkg.Hello(arg1="1", arg2="2") # OK

pkg.Hello(arg1="1") # ERROR: missing an argument
pkg.Hello(arg2="2") # ERROR: missing an argument

all the arguments would always have to be passed to the function or method, but they could also be named.
so it would be mostly syntactic sugar, or self-explaining code.

and you're also right that the not-clearly stated goal of gopy is to be able to wrap all go packages without any modification to these go packages, packages over which you may not have control.

that said, it is still just an idea (with not even a dev-branch in my local git repo), nothing's written in stone yet.
besides, the rejected proposal golang/go#12296 indicates that if maybe some kind of support for functions with named arguments lands in go it would be more like:

type Point struct{x, y int}
func Distance(p Point) float64 { ... }

Distance(Point{1, 2})         // currently permitted
Distance(Point{x: 1, y: 2})   // currently permitted
Distance({1, 2})              // would be permitted if struct type were inferred
Distance({x: 1, y: 2})        // would be permitted if struct type were inferred

I am not sure what would be the best pythonization of such a mechanism...

(I'll cross-ref with the new proposal once it appears on go/issues)

[rcoreilly]

for old version, closing