After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 687697 - Errors when importing a non-existing module are too verbose
Errors when importing a non-existing module are too verbose
Status: RESOLVED DUPLICATE of bug 726877
Product: pygobject
Classification: Bindings
Component: introspection
unspecified
Other Linux
: Normal normal
: GNOME 3.10
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2012-11-05 23:16 UTC by Simon Feltman
Modified: 2014-03-22 19:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Simon Feltman 2012-11-05 23:16:03 UTC
This will give both a logged error and raise and ImportError.

>>> from gi.repository import NonExistingModule
ERROR:root:Could not find any typelib for NonExistingModule
ImportError: cannot import name NonExistingModule

The python importer protocol specifies to return None from "find_module" when something is not found. Python will then raise the appropriate exception for us making the logging message unnecessary. This should be removed from gi/importer.py
Comment 1 Simon Feltman 2012-11-06 00:16:40 UTC
On second thought, the logging might be somewhat useful as it could hint at potential problems in the gi repository itself. In this case we could change it to logging.debug instead of error as this does not show up by default.
Comment 2 Robert Schroll 2012-11-06 02:12:27 UTC
PEP 302 suggests that find_module can raise an error that will be propagated upwards.  Perhaps find_module should raise an ImportError with a custom message describing the problem, instead of just returning None.  (I haven't tested this, though.)
Comment 3 Simon Feltman 2012-11-06 02:25:10 UTC
Yep, that is even better. For some reason I thought doing this would limit the potential of having sub-modules within gi/repository, but testing shows otherwise.
Comment 4 Simon Feltman 2014-03-22 19:47:52 UTC

*** This bug has been marked as a duplicate of bug 726877 ***