Relative Imports, why the hell is it so hard?

Istvan Albert istvan.albert at gmail.com
Wed Mar 25 01:57:12 CET 2009


On Mar 24, 3:16 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:

> Did you know, once a module is imported by the first time

yeah yeah, could we not get sidetracked with details that are not
relevant? what it obviously means is to import it in all of your
modules that need to access to relative paths

> I don't understand, how is this supposed to help relative imports?

That's only because you have not had to deal with the problem that it
solves.
If you need to have a module that can do both:

1. access relative paths (even other packages)
2. be executable on its own (for example a modules may execute its own
doctests when running them directly)

this is the only way to achieve it.

> I'd recommend the oposite - use relative (intra-package) imports when possible.

Does it not bother you that a module that uses relative imports cannot
be run on its own anymore? To me that is irritating because it forces
me to change a habit (running the doctests when the module is
executed) that I consider a very good practice. It is extremely handy
to be writing a module, press a key and the module is executed and I
can see the tests results. The relative import takes away this from
me. Like I said, it is irritating.

> Bindly inserting directories into sys.path can easily confuse the import systemn

confuse the import system? what the heck does that mean? You either
have a path in the sys.path or not. FWIW it is far cleaner than doing
a relative import that does not work correctly.

Istvan

















More information about the Python-list mailing list