On Mon, Jan 24, 2005 at 11:16:29AM +0000, Gustavo J. A. M. Carneiro wrote: > Hello. > > Your arguments may be valid (or not, that's not the point here), but: > > - PyGTK just wraps Gtk+, we should _not_ change gtk+ API semantics, > because having a similar API between PyGTK and Gtk+ is a feature we > should preserve for people that like Python just for prototyping and > later on convert their projects to C, or people converting legacy C > programs to Python. Any problem with threads and signal handlers should > be discussed at gtk-devel list, not here. > > - Both PyGTK and Gtk+ _must_ keep API/ABI compatibility with all > previous versions. If what you propose is not API/ABI compatible, you > have to wait for Gtk+ 3.0, which is not even planned right now, so... > > Keep this in mind before deciding to continue these discussions. > > Best regards.
Well I have decided to drop this part of the discussion. My reasons are as follows: 1) I don't have the time to follow an additional mailing list. 2) The compatabilty wouldn't be a problem in python because of the possibility of parameters with default values but it would be a problem in C. 3) It seems to be a non issue in python since the gtk and gtk.gdk function don't seem to release the GIL, which means they will be serialized automatically. 4) I mostly write my programs so that the gtk and gtk.gdk functions are called in the gtk thread any how. So although I think the current behaviour should be corrected, it seems such a minor issue for me that I can't be bothered to register to an other mailing list to argue the points. -- Antoon Pardon _______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
