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

kokes · 2017-01-12T14:07:29Z

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 · 2017-01-12T18:24:54Z

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 · 2017-01-13T00:57:42Z

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 · 2017-01-13T01:01:28Z

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

S-YOU · 2017-01-13T01:57:18Z

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?


        Support module member import. Fix #99.

Modules being imported are now detected at compile time. So it's possible to determine whether "from x import y" is importing module y or a member y of module x. This change uses this capability to choose whether to import a module or a member. This fixes google/grumpy#99

trotterdylan changed the title ~~from package import x~~ Module attribute imports not supported: from package import x Jan 12, 2017

trotterdylan changed the title ~~Module attribute imports not supported: from package import x~~ from x import y: y can only be a module, not any old attribute Jan 13, 2017

trotterdylan mentioned this issue Feb 6, 2017

from collections import MutableMapping #238

Closed

trotterdylan closed this in a9b0a7b Mar 24, 2017

google / grumpy

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

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

kokes commented Jan 12, 2017

trotterdylan commented Jan 12, 2017

toadzhou commented Jan 13, 2017

trotterdylan commented Jan 13, 2017 •

edited

S-YOU commented Jan 13, 2017 •

edited

google / grumpy

Join GitHub today

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

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

Comments

kokes commented Jan 12, 2017

trotterdylan commented Jan 12, 2017

toadzhou commented Jan 13, 2017

trotterdylan commented Jan 13, 2017 • edited

S-YOU commented Jan 13, 2017 • edited

trotterdylan commented Jan 13, 2017 •

edited

S-YOU commented Jan 13, 2017 •

edited