Repository navigation
absolute import doesn't work for standard python modules #46662
Description
| BPO | 2410 |
|---|---|
| Nosy | @ncoghlan |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2008-04-08.15:09:50.413>
created_at = <Date 2008-03-18.21:27:55.665>
labels = ['interpreter-core', 'type-bug', 'invalid']
title = "absolute import doesn't work for standard python modules"
updated_at = <Date 2008-04-09.03:21:16.538>
user = 'https://bugs.python.org/dangyogi'bugs.python.org fields:
activity = <Date 2008-04-09.03:21:16.538>
actor = 'ncoghlan'
assignee = 'none'
closed = True
closed_date = <Date 2008-04-08.15:09:50.413>
closer = 'ncoghlan'
components = ['Interpreter Core']
creation = <Date 2008-03-18.21:27:55.665>
creator = 'dangyogi'
dependencies = []
files = []
hgrepos = []
issue_num = 2410
keywords = []
message_count = 4.0
messages = ['63993', '65166', '65206', '65231']
nosy_count = 2.0
nosy_names = ['ncoghlan', 'dangyogi']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue2410'
versions = ['Python 2.6', 'Python 2.5', 'Python 3.0']
Activity
dangyogi commentedon Mar 18, 2008
Try this to reproduce error:
$ mkdir -p test/email $ cd test $ touch __init__.py email/__init__.py $ cat <<! > foo.py from __future__ import absolute_import import smtplib ! $ python >>> import foo ... File "/usr/lib/python2.6/smtplib.py", line 46, in <module> import email.utils ImportError: No module named utilsIf you rename the email subdirectory, it will find email.utils where it
should find it.
Strangely, this doesn't happen if you have an 'os' subdirectory and try
to import shlex, which does: import os.path ??
ncoghlan commentedon Apr 8, 2008
Running the interactive interpreter like that places the current
directory on sys.path, so it *is* doing an absolute import of your
pseudo email package. (If it didn't do that, your test would fail at the
"import foo" line)
Instead of cd'ing into test the way you did, invoke the interpreter from
the next directory up and do an import of 'test.foo', and you should see
the absolute imports in the foo module having the desired effect.
(I expect the reason you didn't run into this for the os module is
because the os module is bootstrapped quite early in Python's startup
process, so you'd have to try really hard to get it to see something
other than the builtin standard library version of os)
dangyogi commentedon Apr 8, 2008
OK, I see where I mis-diagnosed the problem. It seems that importing
smtplib (for example) shouldn't get confused with my email package. As
I understand it, using relative imports within a package should avoid
the problem of the names of subordinate packages/modules colliding with
those in other packages. Should the problem have been written up that
the standard modules (e.g., smtplib) should use relative imports to
avoid name collision problems like this? (I'm not sure if relative
imports work for standard modules).
If this is the correct statement of the problem, I can resubmit it if
that's easier.
Thanks in advance!
ncoghlan commentedon Apr 9, 2008
Using relative imports within smtplib wouldn't have made any difference
in this case. Your dummy email package was the first one encountered on
sys.path, so the "import email.smtplib" line (which does an "import
email" internally as the first step in resolving the import, and then
tries to find "smtplib" in email.__path__) picked it up.
Putting an internal package directory on sys.path (as your example does)
is seriously bad ju-ju. It's one of the main reason why people are so
strongly discouraged from directly executing files that are stored in
package directories (along with another nasty side effect in getting two
different copies of the same module using different names, it also has
the same effect as what you did here - subpackages/modules can end up
overriding standard library modules and packages because the script
directory gets placed on sys.path).