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.
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. 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
On 5/6/07, "Martin v. Löwis"
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. 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.
How about an ImportWarning instead? That way people can have either have import halt immediately, or continue (with or without a message). -Brett
""Martin v. Löwis""
Martin v. Löwis schrieb:
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. You might get an ImportError on *any* import, as it tries the unreadable directory first, gets a permission error, and immediately aborts.
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).
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.
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