On Tue, Mar 8, 2016 at 3:19 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote: > On Thu, Mar 3, 2016 at 11:50 AM, Tim Chase > <python.l...@tim.thechases.com> wrote: >> I think that relative imports should ameliorate this, as I usually >> hit it when I'm using smtplib which in turn imports "email" (and, in >> 2.x when it found my local email.py would crash and burn). If it used >> a relative import that forced it to find the one in the stdlib, it >> should(?) prevent it from finding my local version first. > > Relative imports only work inside packages. You can't use a relative > import to import one top-level module from another. > > Besides, the relative import doesn't help to disambiguate in this > case. The absolute path of the stdlib email module is "email". The > absolute path of the module in your CWD is also "email". Why should a > relative import prefer one over the other? So I would think that even > if it worked, it would still just end up importing the first one it > finds on your sys.path.
So the solution is to treat the current directory as a pseudo-package. It'd be a backward-incompatible change, so it would need to be explicitly invoked. Something like: python3 -p somefile.py which would pretend to create an __init__.py in the current directory, change to the parent, and "from dirname import somefile". I mentioned this one time before, but it got kinda missed; I think I'll reraise it on python-ideas. It's a protection on par with not having the current directory in $PATH. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
