[Python-Dev] Relative imports in Py3k

[Nick Coghlan]

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:
- modify PYTHONPATH
- use -m to execute your modules and just switch your current working
directory depending on which version of spyderlib you want to execute

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