➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2014-04-14 01:48 by eric.snow, last changed 2022-04-11 14:58 by admin. This issue is now closed.
| Messages (3) | |||
|---|---|---|---|
| msg216047 - (view) | Author: Eric Snow (eric.snow) *  |
Date: 2014-04-14 01:48 | |
In 3987667bf98f pkgutil.find_loader() switched from using pkgutil.iter_importers() to importlib.find_module(). importlib.find_module() checks the module's __loader__ (and raises ImportError when invalid) whereas iter_importers() does no such check. In 3.4 pkgutil.find_loader() switched over to importlib.util.find_spec(), but the same issue remains. The documentation (and the previous behavior) implies that the ImportError case coming out of find_spec() should result in pkgutil.find_loader() returning None rather than propagating the ImportError. However, it may make more sense to do an explicit check for module.__spec__ before calling find_spec(). |
|||
| msg216460 - (view) | Author: Eric Snow (eric.snow) * |
Date: 2014-04-16 12:57 | |
Ah, it's ValueError rather than ImportError that causes the problem. Regardless, handling it would be necessary. |
|||
| msg216840 - (view) | Author: Eric Snow (eric.snow) * |
Date: 2014-04-19 03:34 | |
On second thought, all modules (except __main__) must have both __spec__ and __loader__ set to their correct respective objects. So the current behavior is correct in that it exposes poorly formed modules. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:58:01 | admin | set | github: 65410 |
| 2014-04-19 03:34:59 | eric.snow | set | status: open -> closed resolution: not a bug messages: + msg216840 stage: test needed -> resolved |
| 2014-04-16 12:57:29 | eric.snow | set | messages: + msg216460 |
| 2014-04-14 01:48:18 | eric.snow | create | |