FAQ

On Wed, Mar 14, 2012 at 7:23 AM, Guido van Rossum wrote:
FWIW, Thomas Wouters disagrees with the goal of PEP 395 -- he would
much rather issue an error message when you're trying to execute a
file living inside a package (without using -m) instead of Nick's
proposal to fix the situation. But that's a second-order issue; Eric's
algorithm (or some variant of it) might work for either approach.
Anyway, I'd like to stay out of *that* particular discussion -- either
way it doesn't affect my position on namespace packages.
Your position on namespace packages definitely affects this part of
PEP 395, though :)

My current thought is that I'll revise the affected portion of the PEP
to add a "importlib._package_hint()" (or similar) that gets invoked to
display a message on stderr when either __main__ or a command at the
interactive prompt raises ImportError. This is still just the
glimmering of an idea and there are a lot of practical details still
to figure out, but it should be feasible to produce errors like those
shown below.

Interactive prompt:

The current working directory appears to be inside a Python
package. This can cause unexpected Import Errors and other strange
behaviour. Consider using "os.chdir('<path>')" to move the working
directory to the parent directory of the package and accessing modules
under their full name.

Module/package execution via -m:

The current working directory appears to be inside a Python
package. This can cause unexpected Import Errors and other strange
behaviour. Consider changing the working directory to the parent
directory of the package ("<path>") and running the command as "python
-m <full name>".

Direct execution:

The script directory appears to be inside a Python package. This
can cause unexpected Import Errors and other strange behaviour.
Consider changing the working directory to the parent directory of the
package ("<path>") and running the command as "python -m <full name>".

Cheers,
Nick.

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

Search Discussions

  • Paul Moore at Mar 13, 2012 at 11:40 pm

    On 13 March 2012 22:37, Nick Coghlan wrote:
    Interactive prompt:

    ? ?The current working directory appears to be inside a Python
    package. This can cause unexpected Import Errors and other strange
    behaviour. Consider using "os.chdir('<path>')" to move the working
    directory to the parent directory of the package and accessing modules
    under their full name.
    [...]

    This remains the crux of my problem with this issue. Changing the current
    directory affects global state. I can *consider* doing so, but I may have
    reasons not to want to. The recommendation offers me no option then.

    An alternative option might be to set PYTHONPATH, but that's also global
    state. (Unix users can do "PYTHONPATH=xxx python" but that's not an option on
    Windows).

    Actually, explaining the problem and issues isn't hard:

    - Apart from sys.path[0], sys.path is static. You know what's on it (basically
    the stdlib and installed packages, except if you get fancy).
    - sys.path[0] is set to the directory containing the executed file, or the
    current directory for interactive use or -m.

    The consequences of this may be unexpected, and they may not be what the user
    would like, but they aren't obscure, surely? (Nick, feel free to tell me I'm
    wrong, and there's a lot more complexity here - but I hope there isn't)

    As Nick says, it's possible to detect when the user has a mistaken view of
    what's happening and issue a warning, but I don't think the warning needs to
    be quite so scary ("strange behaviour"). Something simpler, like the
    following, would be better in my view:

    "You appear to be trying to import the package containing XXX[1]. But the
    Python module path does not include the directory containing that package. You
    can add that directory to the module path either by setting PYTHONPATH, or by
    changing the current directory (and using python -m if you want to execute a
    module in the package)."

    [1] either "the current directory" or "the script you are running" as
    appropriate.

    This has the benefit of explaining the actual problem and its cause, and
    giving the user some alternative options to fix it. (The wording could
    possibly be improved a bit).

    To alleviate the problem of having to alter global state, would it be worth
    having an option (like Java's -classpath option) to add sys.path entries for
    one invocation of Python (Unix users can do "PYTHONPATH=xxx python", but
    that's a bit verbose and not available to Windows users). Something like

    python -P dir1;dir2;dir3 rest_of_args

    which works like temporarily adding dir1;dir2;dir3 to the start of PYTHONPATH.
    If this was added, the error message could offer using -P as another option.

    Paul

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupimport-sig @
categoriespython
postedMar 13, '12 at 10:37p
activeMar 13, '12 at 11:40p
posts2
users2
websitepython.org

2 users in discussion

Paul Moore: 1 post Nick Coghlan: 1 post

People

Translate

site design / logo © 2018 Grokbase