Suppose we have two modules with cyclic dependencies:
# a.py
import b
def f(): return b.y
x = 42
# b.py
import a
def g():
(Incedentally, the relative import doesn't matter. Using from pkg import... reveals the same exception.)
I think what's going on here is that the difference between from foo import bar and import foo.bar is that in the first one, the value bar could be module in pkg foo or it could be a variable in a module foo. In the second case, it's invalid for bar to be anything but a module/package.
This would matter because if bar is known to be a module, then the contents of sys.modules is sufficient to populate it. If it might be a variable in the foo module, then the interpreter must actually look into the contents of foo, but while importing foo, that would be invalid; the actual module has not been populated yet.
In the case of a relative import, we understand from . import bar to mean import the bar module from the package that contains the current module, but this is really just syntactic sugar, the . name is translated to a fully qualified name and passed to __import__(), and thus it looks for all the world like the ambigious from foo import bar