On Mon, Dec 15, 2003 at 09:34:34AM +0100, Felix K�hling wrote: > I think this makes sense. As an example take a missing API feature I > reported recently. widget.modify_xyz could not be passed a None argument > in order to reset the xyz-attribute to the default style. So in my > application I don't use that feature. Imagine a developer who develops > an application with a later patch-level of pygtk that can do > widget.modify_xyz(None) without complaining. However, the application > would break on a slightly older pygtk installation. That would be a major > pain for the application maintainer. It would be ok, however, if the > application could require a pygtk version that is known to always > support widget.modify_xyz(None).
It would only be OK if *actual users had* an updated pygtk version. This is an important point -- relying on getting patches into PyGTK for your application is always risky (specially given the patch process and release turnover time). Which is why I suddenly feel I'm not sure we want to kick the doors open without some evidence that our coverage is good. Then again, you could argue that we'd appreciate the better coverage testing that a larger user base would get us, which points to the way of making the bindings. However, I personally think pygtk.org is more important in attracting new users than being a part of the official bindings, but I'm not putting my hand into the fire for that one yet. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
