[Import-SIG] Updated PEP 395 ("Qualified Names for Modules" aka "Implicit Relative Imports Must Die!")

[Eric Snow]

On Wed, Nov 23, 2011 at 4:05 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sat, Nov 19, 2011 at 10:59 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> The updated version is includes below and has also been updated on
>> python.org if you prefer a nicely formatted version:
>> http://www.python.org/dev/peps/pep-0395/
>>
>> The recent discussion regarding imports from main really crystallised
>> for me what I think is currently wrong with imports from main modules
>> - I was cheering when the Django folks updated their default site
>> template to avoid putting a package directory on sys.path (due to all
>> the problems it causes), but that thread made me realise how easy we
>> make it for beginners to do that by accident, with no real payoff of
>> any kind to justify it.
>>
>> So the PEP now spends a lot of time talking about the fact that our
>> current system for initialising sys.path[0] is almost always just
>> plain wrong as soon as packages are involved, but the explicit markers
>> on package directories make it possible for us to do the right thing
>> instead of being dumb about it.
>
> *crickets*
>
> No feedback at all on the prospect of changing the way we initialise
> sys.path[0] to respect the package information available on the
> filesystem?
>
> Also, Éric Araujo raised an interesting point [1], automatically
> initialising sys.path[0] *at all* can be a problem in some
> circumstances, especially when symlinks are involved. PEP 395 won't
> really help with that (it may change some of the symptoms, but it
> won't fix the general problem), but it does make me wonder if the
> interpreter should have a flag to switch off sys.path[0]
> initialisation (similar to the existing flags to disable site
> processing, user site processing and processing of the PYTHONHOME and
> PYTHONPATH environment variables).

That sounds good to me.

Relatedly, and this will reflect my relative inexperience here, I
still don't have a clear picture of why we do the sys.path[0]
initialization in the first place.  I'm sure there's a good reason,
but I've never (knowingly) met it.  :)

Is it so that modules on which the script relies don't have to be put
in a package under some sys.path directory (to be explicitly
imported), saving a little time during development or simplifying
packaging a little?  Seems to me like that sort of thing is
addressable in better, more obvious ways, but especially that the
benefits of the implicit initialization don't outweigh the problems it
causes (hence PEP 395).

Unless you think to read the sys.path doc entry, you won't know about
the sys.path[0] initialization for scripts, and wonder why you keep
getting implicit relative imports when you aren't expecting them.  I
would think that would be more impactful across the spectrum of Python
experience than (what seem like minor) benefits gained from the
implicit initialization.

So, at this point, is it just an artifact of early Python, when better
solutions weren't around yet?  What am I missing here?

-eric

>
> [1] http://bugs.python.org/issue10318 (last couple of comments)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Import-SIG mailing list
> Import-SIG at python.org
> http://mail.python.org/mailman/listinfo/import-sig
>