Re: Eliminating implicit __main__ relative imports

On 28 March 2017 at 20:38, Paul Moore <[email protected]> wrote:
> On 28 March 2017 at 11:25, Nick Coghlan <[email protected]> wrote:
>> Thanks to PEP 366, cross-version compatible main-relative imports
>> would then look like:
>>
>>     if __package__ is not None:
>>         from . import relative_module_name
>>     else:
>>         import relative_module_name
>
> I'd be a little concerned that certain types of program (adhoc scripts
> and the like that got too big to be a single file) would be broken by
> this. Even if they *don't* care about cross-version compatibility,
> they'd need to change from "import foo" to "from . import foo". I
> honestly don't know how common this problem would be - I've tried to
> think what programs I have that would be affected, and honestly, my
> feeling is that it's either very few, or it's a lot but I use
> main-relative imports so automatically that I can't remember any ;-)
> (Although TBH, I think the former, based on the fact that most of my
> adhoc scripts are very small).
>
> The particular concern is that if it *is* an issue, it'd mostly hit
> the sort of code that doesn't get published on the web, so it's
> probably pretty hard to get a sense of the scale of the impact.

Yeah, that's why I considered coming up with a plausible transition
plan (where the explicit relative imports work, and the implicit
relative imports emit a deprecation warning) to be an essential aspect
of being able to even consider the idea.

Rather than deprecation and eventual removal, another option would be
to make the implicit main-relative imports instead emit a
RuntimeWarning, since those are intended to cover "dubious runtime
features" without implying any kind of timeline for getting rid of
them entirely. If we did that, then "sys.main_path_entry" could become
a public attribute, allowing the use of
"sys.path.remove(sys.main_path_entry)" to explicitly disable implicit
main-relative imports.

That way folks potentially affected by name shadowing would get an
explicit warning in addition to the resulting cryptic misbehaviour,
while folks deliberately doing main-relative imports could choose
between living with the warning, suppressing it through the warning
system's options, or switching to explicit relative imports.

Cheers,
Nick.

P.S. As an interesting side benefit of the proposed approach, folks
would also be able to do "from . import __path__ as
main_relative_path" to get access to the list of directories that are
searched for top-level explicit relative imports, which could prove to
be less error prone than manipulating sys.path and potentially
affecting *all* imports, rather than just main-relative ones. You'd
also be able to do "main_relative_path.clear()" to disable even
explicit main-relative imports.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia