[Python-Dev] Relative imports in Py3k (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Mon Oct 11 14:27:47 CEST 2010

On Mon, Oct 11, 2010 at 1:54 AM, anatoly techtonik <techtonik at gmail.com> wrote:

On Sun, Sep 26, 2010 at 2:32 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

This is almost certainly failing because the directory containing the spyderlib package isn't on sys.path anywhere (instead, whichever directory contains the script you executed directly will be in there, which will be somewhere inside the package instead of outside it). Put the appropriate directory in PYTHONPATH and these tests should start working. This is a hack. I use relative imports, because I don't want to care about PYTHONPATH issues. I work with two clones of spyderlib (reference point and feature branch). You propose to switch PYTHONPATH every time I want to execute debug code in the main section from either of them.

Anatoly, unconstructive responses like this are why people often react negatively to your attempts to be "helpful".

I specifically mentioned 2 things you could do:

Responding to that by telling me that modifying PYTHONPATH when working with in-development code is clumsy isn't telling me anything I don't already know. There's a reason why you can now use -m to have relative imports "just work" so long as your current working directory includes the top level directory for your package. There's a reason we added the ability to execute directories and zipfiles and have them automatically add themselves to the head of sys.path. And it's the same reason: we've been working on making it easier to work with uninstalled (i.e. not on PYTHONPATH) code for years. Throwing your hands up and saying "bah, it doesn't work, it should just read my mind and know what I meant!" really isn't helpful.

Based on your latest response, giving your spyderlib package a top-level main.py and running the directory directly may even be an option for you. But when your response solely discusses PYTHONPATH without even mentioning the better alternative I offered (i.e. using -m and just switching your current working directory in a command shell), it's hard to assess your actual use case.

As far as documentation goes, I personally find it incredibly difficult to write simple, user-oriented documentation of the import system, as I've long since lost my perspective on what's simple and what's complicated when it comes to the import system. I'd love for someone to tackle the task of writing clear end-user documentation of the whole PEP 302, 328, 338, 366, imp, runpy, importlib, etc arrangement (more comprehensive documentation of the zipfile and directory execution from issue 1739468 wouldn't hurt either).

The problem is that the people who already know enough to write such documentation don't need it, and anyone else that sets out to learn enough to be able to write it discovers that there are so many backwards compatibility hacks that complicate an otherwise reasonably clean design that they throw their hands up in despair. (That said, I did attempt to write such a piece of documentation a few years back [1] so anyone that wanted to try it could at least consider using that as a starting point instead of starting with a blank screen)

Cheers, Nick.

[1] http://svn.python.org/view/sandbox/trunk/userref/ODF/Chapter07_ModulesAndApplications.odt

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list