On 16/07/13 22:02, Thomas Wouters wrote:
On Tue, Jul 16, 2013 at 1:40 PM, Nick Coghlan <ncogh...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
