[pygtk] CVS branches and plans for the future.
James Henstridge
james at daa.com.au
Wed Sep 3 17:19:36 WST 2003
On 3/09/2003 9:50 AM, Malcolm Tredinnick wrote:
> Firstly, sincere congratulations on making the 2.0.0 releases. It is
>
>wonderful to see all your hard work over the years pay off so far. :)
>
Thanks!
[stuff about pygtk future]
>Agreed.
>
>
[stuff about pyorbit]
> Yes and yes.
>
>What do you think about moving the gtksourceview bindings into the main
>module (I'm not sure where exactly in the directory tree)? This is all
>said without having talked to the maintainer about his plans, but I like
>the idea of having a single-source download for this kind of stuff.
>Things like vte are different, since it includes the Python bindings in
>the main module.
>
This is an interesting question. I really don't want to stick bindings
for too many libraries into the pygtk tarball. I think it is a good
thing that it is fairly low in the dependency stack, since it makes it
easier for other packages to depend on pygtk for their builds.
Making these sort of things optional dependencies is really a copout
though. For people building packages (ie. Linux distros, etc), the
optional dependencies are essentially hard dependencies if they want all
features of the package to be built (even if they then split things up
into multiple binary packages). If pygtk has an optional dependency on
libfoo, then other packages that depend on pygtk (optional or not) will
also depend on libfoo. If these dependencies get too complex, they are
likely to either (a) not build pygtk's libfoo binding, or parts of other
packages that depend on pygtk.
Now it might make sense to distribute the GtkSourceView binding with
gnome-python. Alternatively, it might make sense to package them with
GtkSourceView itself (like with VTE). I don't know.
>>Any comments?
>>
>>
>My only real request is to continue supporting Python 2.2. I was one of
>the people in favour of requiring 2.2 early on, so this risks sounding
>hypocritical, but the changes between 2.2 and 2.3 are not as large as
>from 2.1 to 2.2 and there will be a lot of installations with no plans
>to upgrade for some time. (OK, this is partly selfish: I've just got
>people at work beginning to use some apps in PyGTK and we have no
>upgrade plans in the near future for a large number of pragmatic
>reasons.)
>
>(In case that sounds wrong in email, I am not sure what your plans are
>-- this is just a pre-emptive $0.02 strike. :-) )
>
There is one big improvement in Python 2.3 that would be worth making
use of: the new PyGILState APIs, which could significantly reduce the
complexity of PyGTK's thread support (and get it to play nicer with
other threading aware Python extensions):
http://www.python.org/peps/pep-0311.html
It is definitely worth experimenting here. Whether we go for
conditional compilation, or disabling threading for Python 2.2, or not
make use of it at all is not clear.
For a non-threaded build, I see no reason to require 2.3 though.
James.
--
Email: james at daa.com.au
WWW: http://www.daa.com.au/~james/
More information about the pygtk
mailing list