[Python-ideas] Idea: Importing from arbitrary filenames

[Brett Cannon]

On Mon, 16 Apr 2018 at 09:58 Eric Fahlgren <ericfahlgren at gmail.com> wrote:

> The documentation is pretty opaque or non-existent on other aspects of
> importlib use, too.
>

Well, we are diving into the dark corners of import here. (Details can be
found in the language reference:
https://docs.python.org/3/reference/import.html).


>   If I enable warnings, I see this (and many more like it).  I've read PEP
> 302 a couple times, read the code in importlib that detects the warning and
> searched down several rabbit holes, only to come up empty...
>
> T:\Python36\lib\importlib\_bootstrap.py:219: ImportWarning: can't resolve
> package from __spec__ or __package__, falling back on __name__ and __path__
>
> My thoughts when I see it: "Ok.  So what does that mean?
>

It means that the mechanisms import typically uses to calculate the
importing module's name in order to resolve relative imports wasn't where
it should be, and so we fell back to the Python 2 way of doing it.


>   Is it bad?
>

Eh, it isn't ideal. ;)


>   It must be bad, otherwise I wouldn't get a warning.  How do I reconcile
> __spec__ and __package__?
>

You should be setting __spec__.parent, but we will fall back to __package__
if that doesn't exist (and raise a different warning). :)


>   Which one is missing and/or incorrect?"
>

Both are missing. :)

-Brett


>
>
> On Mon, Apr 16, 2018 at 9:36 AM, Paul Moore <p.f.moore at gmail.com> wrote:
>
>> On 16 April 2018 at 17:22, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> > If we're not covering explicit __path__ manipulation anywhere, we
>> > should definitely mention that possibility.
>> > https://docs.python.org/3/library/pkgutil.html#pkgutil.extend_path
>> > does talk about it, but only in the context of scanning sys.path for
>> > matching names, not in the context of building a package from an
>> > arbitrary set of directory names.
>>
>> It's quite possible that we're not.
>>
>> > I'm not sure where we could put an explanation of some of the broader
>> > implications of that fact, though - while __path__ manipulation is
>> > usually fairly safe, we're always a little hesitant about encouraging
>> > too many dynamic modifications to the import system state, since it
>> > can sometimes have odd side effects based on whether imports happen
>> > before or after that state is adjusted..
>>
>> One of the problems with PEP 302 was that there was no really good
>> place in the documentation to put all the information that was present
>> (certainly not in the version of the docs that was around when we
>> wrote it). So a lot of the important details remained buried in PEP
>> 302. Since then, a lot of the details ended up in the docs, mostly in
>> the importlib sections, but I don't recall ever seeing anything about
>> __path__ (and particularly not the nice summary you gave, "packages
>> are ultimately just modules with a
>> __path__ attribute that works like sys.path".
>>
>> Paul
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180416/f667db24/attachment.html>