[Python-Dev] question/comment about documentation of relative imports (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Tue Oct 5 20:23:17 CEST 2010

On Tue, 5 Oct 2010 14:17:47 -0400 Darren Dale <dsdale24 at gmail.com> wrote:

>> Thats not the point though. Due to compatibility issues, maybe I don't >> want to expose the code at the top level. Maybe the foo package is >> distributed elsewhere as a top-level package, but I need to use an >> older version due to compatibility problems. I certainly don't want to >> risk overwriting a pre-existing installation of foo with my required >> version of foo. This is not a hypothetical, we once had exactly this >> problem when we distributed an old version of enthought.traits with >> matplotlib > > That use case requires that the third-party package, not your package, > use relative imports. I don't think you can require other projects to > follow your coding style recommendations (unless of course you maintain > both).

I'm not talking about requiring other projects to follow my coding style.

Then can you explain your use case a bit better? It is not obvious at all what kind of "solution" relative imports allow, and why not using them is a heavy burden.

> I'm not sure I understand the issue.

The issue is implementing a PEP with nice support for relative imports, and then documenting that it should never be used.

While I haven't written the FAQ, I certainly sympathize with the idea that relative imports are much less readable than absolute imports (especially when they climb upwards in the directory hierarchy, i.e. "from ..foo import bar").

Regards

Antoine.

More information about the Python-Dev mailing list