On Wed, Aug 11, 2010 at 10:57, Simon van der Linden <svdlin...@gnome.org> wrote: > On Wed, 2010-08-11 at 10:07 +0200, Tomeu Vizoso wrote: >> The rationale is that it will help people a bit to know what to expect >> from a given PyGObject release. He's already numbering his PyGtk >> releases matching Gtk+ versions. > > I wonder whether it makes sense for PyGObject, which is not, to my > knowledge, a set of static binding for GLib. We don't exactly ensure > that all the features available in the matching GLib version is > available to Python developers, do we?
I think that's something we should aim for. I also consider g-i to be a logical part of GLib even if it hasn't been merged yet. It's true PyGObject doesn't aim to be a set of static bindings in the same way that PyGtk does, but then GLib has lots of infrastructure stuff that doesn't make sense to expose to Python as-is. In summary, while PyGObject won't try to wrap every bit of GLib, it should aim to expose to Python all the functionality that makes sense, for each version. Regards, Tomeu > Regards, > > Simon > > > _______________________________________________ > python-hackers-list mailing list > python-hackers-l...@gnome.org > http://mail.gnome.org/mailman/listinfo/python-hackers-list > _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
