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

[Nick Coghlan]

On Thu, Nov 24, 2011 at 11:18 AM, PJ Eby <pje at telecommunity.com> wrote:
>
> On Wed, Nov 23, 2011 at 6:05 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> 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?
>
> I gave you feedback previously: I think guessing based on __init__ files
> introduces new breakage potential at a distance for things that didn't break
> before.  It'll also guess the wrong location when somebody bundles a
> dependency inside their package, and you try to run a script from the
> embedded package.

And you have yet to explain how that is in any way inferior to the
status quo where we are consistently doing something that we *know* is
wrong (i.e. putting a package directory directly on sys.path).

Assuming people have their package layouts correct is *not* guessing,
no matter how many times you try to claim it is. Calling that guessing
is like saying that module name shadowing on sys.path (or any form of
name shadowing) is guessing. It may not be what the user intended, but
that doesn't mean the interpreter is wrong to believe the information
the user is providing.

The status quo sucks - as soon as you put a python file inside a
package, almost *every* method we offer to invoke it breaks. Direct
command line invocation breaks, double-clicking in a file browser
breaks, running from Idle breaks, even importing it or using the -m
switch only work if you're in the right working directory. All it
takes is one perfectly reasonable assumption (that the filesystem
package layout is correct), and we can *fix* all that just by being a
bit smarter about the way we figure out sys.path[0].

Hypothetical "oh, but this bizarre situation with a clearly broken
package layout that only worked by accident might now start breaking
when it worked before" scenarios are a lousy argument for not fixing
the behaviour of the interpreter for the vast majority of people that
are doing the right thing.

Cheers,
Nick.

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