ImportError on no permission
Today, I got a request regarding importing semantics. When a module file cannot be opened because of, say, lacking read permission, the rest of sys.path will be tried, and if nothing else is found, you get "no module named foo". The reporter claimed, and I understand that, that this is a pain to debug and it would be good to at least add a better message to the import error. Now, why don't we change the semantics as follows: if a file with matching name exists (in import.c::find_module), but opening fails, ImportError is raised immediately with the concrete error message, and without trying the rest of sys.path. That shouldn't cause any working and sane setup to break, or did I overlook something obvious here? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
I wonder how this would behave if a directory on sys.path was unreadable. You might get an ImportError on *any* import, as it tries the unreadable directory first, gets a permission error, and immediately aborts. Now, I think it is quite possible that you have inaccessible directories on sys.path, e.g. when you inherit PYTHONPATH from a parent process. So I would rather let importing proceed, and add a note to the error message that some files could not be read. Regards, Martin
""Martin v. Löwis"" <martin@v.loewis.de> wrote in message news:463E20F1.5000102@v.loewis.de... |> Now, why don't we change the semantics as follows: if a file with matching name | > exists (in import.c::find_module), but opening fails, ImportError is raised | > immediately with the concrete error message, and without trying the rest of | > sys.path. That shouldn't cause any working and sane setup to break, or did I | > overlook something obvious here? | | I wonder how this would behave if a directory on sys.path was | unreadable. I understood Brett to be talking about a different case where the directory *is* readable and the target file shows up in the directory list. In this limited case, stopping seems sane to me. | You might get an ImportError on *any* import, as | it tries the unreadable directory first, gets a permission error, | and immediately aborts. Not if the patch is properly and narrowly written to only apply to unreadable files in readable directories. tjr
Martin v. Löwis schrieb:
That case should be handled differently, yes. My case is that you have a file in the directory with the correct name, but opening it fails (this obviously requires a two-step process, first find the file, then open it).
The warning idea is also fine with me, if it's limited to the above case. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
I wonder how this would behave if a directory on sys.path was unreadable. You might get an ImportError on *any* import, as it tries the unreadable directory first, gets a permission error, and immediately aborts. Now, I think it is quite possible that you have inaccessible directories on sys.path, e.g. when you inherit PYTHONPATH from a parent process. So I would rather let importing proceed, and add a note to the error message that some files could not be read. Regards, Martin
""Martin v. Löwis"" <martin@v.loewis.de> wrote in message news:463E20F1.5000102@v.loewis.de... |> Now, why don't we change the semantics as follows: if a file with matching name | > exists (in import.c::find_module), but opening fails, ImportError is raised | > immediately with the concrete error message, and without trying the rest of | > sys.path. That shouldn't cause any working and sane setup to break, or did I | > overlook something obvious here? | | I wonder how this would behave if a directory on sys.path was | unreadable. I understood Brett to be talking about a different case where the directory *is* readable and the target file shows up in the directory list. In this limited case, stopping seems sane to me. | You might get an ImportError on *any* import, as | it tries the unreadable directory first, gets a permission error, | and immediately aborts. Not if the patch is properly and narrowly written to only apply to unreadable files in readable directories. tjr
Martin v. Löwis schrieb:
That case should be handled differently, yes. My case is that you have a file in the directory with the correct name, but opening it fails (this obviously requires a two-step process, first find the file, then open it).
The warning idea is also fine with me, if it's limited to the above case. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
participants (4)
-
"Martin v. Löwis" -
Brett Cannon -
Georg Brandl -
Terry Reedy