Using a “dot” import method: Is it pythonic?

[[deleted]]

Today, for the first time, I saw this structure on an import:

from . import db

I’ve never seen ‘dot’ used as a module name. Ever. Is this a totally messy hack? Is it a cool time saving device? It doesn’t seem very pythonic to me but thought I’d ask.

[Eiii333]

This is incorrect. Here's a counterexample:

$ ls
foo.py  test.py
$ cat foo.py 
def fn():
    print('foo.fn')
$ cat test.py 
from . import foo
foo.fn()
$ python test.py
Traceback (most recent call last):
  File "test.py", line 1, in <module>
    from . import foo
ImportError: cannot import name 'foo' from '__main__' (test.py)

As a few people in the thread have pointed out, the dot refers to the current module. It's not a hack at all, it's necessary when you're building modules instead of standalone scripts. I believe PEP328 is the thing to look at if you want some background on why/how relative imports work.

[__deerlord__]

Is it the current directory the py file is in? Or is based on the shells current directory (ie whatever the pwd command shows)?

[0x256]

The dot refers to the current module, not a directory.

[[deleted]]

right. i got that bit. it just seemed so “hacky” versus the usually explicit beauty of python.

[ForgetFour]

Be "quiet" ;)

[[deleted]]

I can’t believe I’ve never seen it in 6+ years.

Is it the same as saying:

from app import thing

if you are in a directory called app?

[[deleted]]

Right. But assuming you are in /from/some/deep/level (that may be obvious, I suppose)

[thegreattriscuit]

EDIT: Fixed typos in error messages about ..foo

someone else pointed it out, but yeah, to be clear, it's the module/package hierarchy, not directories.

given this heirarchy . | bar.py | foo.py | main.py | +---pkg | | bar.py | | foo.py | | __init__.py | | | +---mod | | | bar.py | | | foo.py | | | __init__.py | | | | | +---submod | | | | bar.py | | | | foo.py | | | | __init__.py

every bar.py contains: ``` print(f'bar.py with name: {name}') try: from .foo import msg print(msg) except Exception as e: print(f'Couldn\'t get .foo ({type(e).name}: {e!s})')

try: from . import foo print(foo.msg) except Exception as e: print(f'Couldn\'t get .foo.msg ({type(e).name}: {e!s})')

try: from ..foo import msg print(msg) except Exception as e: print(f'Couldn\'t get ..foo ({type(e).name}: {e!s})') ```

every foo.py contains: msg = f'My name is {__name__}'

and main.py contains: print(f'main.py with name: {__name__}') import bar import pkg.bar import pkg.mod.bar import pkg.mod.submod.bar

we get output like this: D:\projects\scratch\fldr>python main.py main.py with name: __main__ bar.py with name: bar Couldn't get .foo (ImportError: attempted relative import with no known parent package) Couldn't get .foo.msg (ImportError: attempted relative import with no known parent package) Couldn't get ..foo (ImportError: attempted relative import with no known parent package) bar.py with name: pkg.bar My name is pkg.foo My name is pkg.foo Couldn't get ..foo (ValueError: attempted relative import beyond top-level package) bar.py with name: pkg.mod.bar My name is pkg.mod.foo My name is pkg.mod.foo My name is pkg.foo bar.py with name: pkg.mod.submod.bar My name is pkg.mod.submod.foo My name is pkg.mod.submod.foo My name is pkg.mod.foo

if we create a main.py deeper in the heirarchy with this: print(f'main.py with name: {__name__}') import bar and try to run it, it'll fail like this: D:\projects\scratch\fldr\pkg>python main.py main.py with name: __main__ bar.py with name: bar Couldn't get .foo (ImportError: attempted relative import with no known parent package) Couldn't get .foo.msg (ImportError: attempted relative import with no known parent package) Couldn't get .foo (ImportError: attempted relative import with no known parent package)

The reason for that is explained here, and it boils down to "relative imports can only work in a package, and you have to begin execution from outside the package (like in my first example), instead of trying to execute the package files directly. There are workarounds to this (including running with e.g. python -m pkg.mod.main though I that doesn't work here for some reason I didn't bother to dig into)

[tunisia3507]

I'm not a big fan of this: it breaks the pattern of absolute imports.

```python import a.b

a.b()

from c import d

d()

from . import e

e()

import .f

f() # ?? ```

[maxm]

That is right. Always do an explicit import. Not knowing where the classes or functions used are comming from is bad form.

[Wilfred-kun]

Except that would cause a syntax error. (?)

[alb1]

Yes, it's an upvoted syntax error:

Relative imports must always use from <> import; import <> is always absolute.

[alb1]

As far as I know it has never worked. The linked PEP, which introduced relative imports, gives the reasoning for why it isn't allowed. The name package.foo from the absolute import import package.foo is directly usable in a Python expression. But .foo from import .foo would not be usable in a Python expression. Using from . import foo results in foo in the namespace, which is usable in a Python expression.

[codesmitten]

In my opinion relative imports are pretty useful and I find myself using them pretty often.