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 639232 - Imported modules do not show which typelib file they are using.
Imported modules do not show which typelib file they are using.
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: introspection
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2011-01-11 17:12 UTC by Laszlo Pandy
Modified: 2011-01-12 13:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Add a __repr__() method to DynamicModule. (745 bytes, patch)
2011-01-11 17:16 UTC, Laszlo Pandy
none Details | Review
Add a __repr__() method to DynamicModule. (1.28 KB, patch)
2011-01-11 18:37 UTC, Tomeu Vizoso
committed Details | Review

Description Laszlo Pandy 2011-01-11 17:12:03 UTC
Normal modules in python have a meaningful repr() string which includes the path of the module's file. For example:
>>> import os
>>> repr(os)
"<module 'os' from '/usr/lib/python2.6/os.pyc'>" 

Modules imported from gi.repository should include the path of the typelib file in the repr() string so that developers can see what file was used to dynamically generate the module.
Comment 1 Laszlo Pandy 2011-01-11 17:16:23 UTC
Created attachment 178067 [details] [review]
Add a __repr__() method to DynamicModule.

This patch adds a __repr__() method to DynamicModule so that modules provide a meaningful string with the typelib path included:

>>> from gi.repository import Gtk
>>> Gtk
<gi.module.DynamicModule 'Gtk' from '/home/laszlo/Dev/gnome-jh-install/lib64/girepository-1.0/Gtk-3.0.typelib'>
Comment 2 Tomeu Vizoso 2011-01-11 18:37:29 UTC
Created attachment 178074 [details] [review]
Add a __repr__() method to DynamicModule.

This patch adds a __repr__() method to DynamicModule so that modules provide a
meaningful string with the typelib path included:

>>> from gi.repository import Gtk
>>> Gtk
<gi.module.DynamicModule 'Gtk' from
'/home/laszlo/Dev/gnome-jh-install/lib64/girepository-1.0/Gtk-3.0.typelib'>
Comment 3 Tomeu Vizoso 2011-01-11 18:43:38 UTC
Thanks!

Attachment 178074 [details] pushed as 4992dca - Add a __repr__() method to DynamicModule.
Comment 4 Simon van der Linden 2011-01-11 22:27:59 UTC
I don't think this patch was good enough to be committed. Instead of calling repository.require directly and later repository.get_typelib_path, __repr__ should call _import as in __getattr__, and use the __path__ that is set.

A similar comment applies to __dir__ as well but that is out of the scope of this bug.
Comment 5 Tomeu Vizoso 2011-01-12 10:36:28 UTC
(In reply to comment #4)
> I don't think this patch was good enough to be committed. Instead of calling
> repository.require directly and later repository.get_typelib_path, __repr__
> should call _import as in __getattr__, and use the __path__ that is set.

And why is that better?
Comment 6 Simon van der Linden 2011-01-12 12:40:39 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > I don't think this patch was good enough to be committed. Instead of calling
> > repository.require directly and later repository.get_typelib_path, __repr__
> > should call _import as in __getattr__, and use the __path__ that is set.
> 
> And why is that better?

Because it reuses code that is already there instead of duplicating it.
Comment 7 Tomeu Vizoso 2011-01-12 13:21:20 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > I don't think this patch was good enough to be committed. Instead of calling
> > > repository.require directly and later repository.get_typelib_path, __repr__
> > > should call _import as in __getattr__, and use the __path__ that is set.
> > 
> > And why is that better?
> 
> Because it reuses code that is already there instead of duplicating it.

We want to ensure that the typelib is loaded, not do the whole import dance.

I don't think discussing this choice is a good use of maintainer time, and also that we should have accepted any of the two options, at the submitter discretion.