[Python-Dev] Why does PEP 8 advise against explicit relative imports? (original) (raw)

Steven D'Aprano steve at pearwood.info
Wed Jul 17 03:55:42 CEST 2013

On 16/07/13 22:02, Thomas Wouters wrote:

On Tue, Jul 16, 2013 at 1:40 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

PEP 8 advises developers to use absolute imports rather than explicit relative imports.

Why? Using absolute imports couple the internal implementation of a package to its public name - you can't just change the top level directory name any more, you have to go through and change all the absolute imports as well. You also can't easily vendor a package that uses absolute imports inside another project either, since all the absolute imports will break. The problem with relative imports (both explicit and implicit) is that it makes it less obvious when you are importing a module under the wrong name. If a package ends up in sys.path directly (for example, by executing something that lives inside it directly) then an explicit relative import directly in the package will fail, but an explicit relative import in a sub-package won't, and you can end up with the subtly confusing mess of multiple imports of the same .py file under different names.

I don't understand this objection. What do you mean by "importing a module under the wrong name"?

As I see it, if relative imports are a bad idea for the std lib, they're a bad idea for everyone. (What am I missing?) So why do we have relative imports? Was it a mistake? I don't think so.

It seems to me that you're giving some fairly obscure edge cases, if I've understood you correctly. If adding a package directory to sys.path breaks relative imports, isn't that an argument against adding the package directory to sys.path rather than relative imports?

What's the concrete benefit of using absolute imports that overcomes these significant shortcomings in maintainability and composability? In my experience changing the name of a package is problematic for more reasons than just 'import'. We used to do the put-in-a-package thing for third-party packages at Google, and we quit doing it because it was just too painful: it's hard to find all the places that reference the package by name (think of import, or mucking in sys.modules),

Again, these are some fairly odd edge cases. I don't mean to imply that they never occur in practice, obviously they do, but perhaps you're overly sensitive to them. It seems strange to me that PEP 8 should recommend against using relative imports for the 49 packages that would benefit from it just to avoid problems with the 1 that does weird things with import or manually mucks about with sys.modules.

Have I missed something?

Even so, there's no reason for the standard library to use explicit relative imports, and that's what PEP 8 is supposed to cover, right? :)

If a third-party package uses relative imports, are you suggesting that those rel imports should be turned into absolute imports as a precondition of it being moved into the std lib?

-- Steven

More information about the Python-Dev mailing list