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 <[email protected]> > > 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. This is less the case on linux where your distribution/package manager hides it from you. John _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://faq.pygtk.org/
