[Python-Dev] Why does PEP 8 advise against explicit relative imports?

[Steven D'Aprano]

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