On 08/11/2010 06:04 AM, John Stowers wrote: > On Wed, 2010-08-11 at 11:44 +0200, Simon van der Linden wrote: >> On Wed, 2010-08-11 at 11:08 +0200, Tomeu Vizoso wrote: >>> 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. >> >> I'm neither in favor nor against this change. I think it will not bring >> anything. > > I have lost track of the number of times I have had to explain the > versions of Gtk, PyGtk, Glib and PyGObject to people trying to get stuff > to work on windows, and every time noted that the version mismatches > were unhelpful, confusing and often resulted in them trying > build/runtime combinations that did not work.
I'm not on most of the cc:d lists, so this might bounce. I have this exact problem. I try a bunch of build/runtime combinations until I find one that works. Even if the version number scheme doesn't change so that things match, there should at least be a table somewhere that tells you which version of the bindings goes with which version of the bound library. If such a thing already exists for PyGtk and PyGObject, I'd love to know where it is. /will _______________________________________________ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/