from x import y: y can only be a module, not any old attribute

[kokes]

Importing certain classes or other objects from packages results in packages not found. E.g. os.path works just fine (from os import path), because build/src/os/path exists, but many packages (I came across math and collections) are implemented in a single Go file, so things like from math import pi or from collections import defaultdict will fail like this:

$ cat mth.py
from math import pi
print pi
$ ./build/bin/grumpc mth.py > mth.go
$ go run mth.go
mth.go:5:2: cannot find package "grumpy/lib/math/pi" in any of:
	/usr/local/Cellar/go/1.7/libexec/src/grumpy/lib/math/pi (from $GOROOT)
	/Users/ondrej/(...)/grumpy/build/src/grumpy/lib/math/pi (from $GOPATH)

Importing the package as a whole works just fine:

$ cat mth.py
import math
print math.pi
$ python2 mth.py
3.14159265359
$ ./build/bin/grumpc mth.py > mth.go
$ go run mth.go
3.141592653589793

Maybe I'm missing something. I'm running b730a44.

[trotterdylan]

Thanks for reporting this. This is a limitation of the current import system: you can only import whole modules not individual members from the module. The reason is for the statement from foo import bar, the compiler currently doesn't know whether bar is a module or a member, so it assumes it's a module. For the compiler to know better it would have to examine the GOPATH (or the PYTHONPATH I suppose) to make that determination.

I've added this to the missing features list.

[toadzhou]

Can not use Python's own modules?
Can I use Golang's modules only? Python connection built-in json modules are not, but do not Python source inside the third-party libraries.

[trotterdylan]

Modules work, but you must name a module, not it's members in a 'from package import x'.

[S-YOU]

I think that is intentional because of Google style guide prohibit it according to this.

  # NOTE: Assume that the names being imported are all modules within a
  # package. E.g. "from a.b import c" is importing the module c from package
  # a.b, not some member of module b. We cannot distinguish between these
  # two cases at compile time and the Google style guide forbids the latter
  # so we support that use case only.

May be worth to mention somewhere in docs?