Re: [pygtk] moving some stuff from pygobject to pygtk

Hmm, seems my original e-mail never made it to the list.  Thanks for posting this Tomeu.

----- "John Stowers" <john stowers lists gmail com> wrote:

> On Fri, 2010-08-20 at 17:54 +0200, Tomeu Vizoso wrote:
> > Hi all,
> > 
> > as you may know J5 is working on the Python3 port of PyGObject and
> he
> > has found that porting the gio static bindings is a lot of work and
> > somewhat useless as the rest of the static bindings aren't likely
> to
> > be ported to Python 3 at all.
> > 
> > I would like to put for consideration the idea of moving gio from
> > pygobject to pygtk, so it is not destabilized by pygobject's port
> to
> > Python 3. The code generator is in the same situation, so it could
> > also be moved to pygtk.
> Would it be easier to put the static gio bindings in their own
> repository/package? 

Easier isn't the word but a one time pain of setting up a new project and creating a new autotools build shouldn't be too bad.

> How do we imagine this playing out with
> dependencies? Does the distributor build two binary packages from the
> PyGObject sources (one against Python-2, one against Python-3)?
> PyGtk -deps-> PyGIO + PyGObject(2) -> Python-2
> and
> gir-packages -> PyGObject(3) -> Python-3

Yes there will be a Python 2 and Python 3 package with their own dependencies.

> I don't think they belong in pygtk.

Thinking about this I think you are right since the split happened so we could support applications that wanted to use glib but didn't want to have an X dependency.

> As for the code generator, it was quite a pain when it moved from
> pygtk
> to pygobject wrt. build setups. What is the problem with it staying
> in
> PyGObject if the GIO stuff moves out?

Nothing really, I already disabled gio in my local build and even ported the generator so it ran in py3k (though the output doesn't compile).  The port was really just fixing up some deprecated syntax such as setting error strings using the exception constructor (parenthesis) instead of using a comma (e.g. Exception("error string") instead of Exception, "error string").  The biggest issue is that a code generator seems strange in a package that doesn't actually use it.     

> > I know that pygtk doesn't have an excess of maintainers right now,
> but
> > these modules should be relatively mature already.
> Agree. I was one of the first large-scale users of the GIO bindings,
> and
> they took at least 2 cycles to get to a stable state.
> Finally, I would be saddened if the port to Python3 destabilised
> PyGObject very much. PyGObject is stable software, and backward
> compatibility breakages should be unacceptable (but deprecations
> welcomed).

Agreed.  We aren't changing things too much here, and right now Python 2 compatibility is the review criteria for py3k patches.  The idea is with the macros applied we get the same exact code in Python 2 as we had in the past (richcompare slot is an exception here).  

> > 
> > There's also the question of what to do with the Gtk and Gdk
> overrides
> > in and
> their
> > tests, which don't really belong to pygobject.

They should ship with their upstream packages once we have stabilized.  Right now we need the ability to release often and experiment so it is fine that the first generation gets shipped with pygobject but as we go into maint mode it makes more sense that the library developers also concern themselves with binding overrides (and in reverse, the binding developers work inside the project in question) 

John (J5) Palmieri
Software Engineer
Red Hat, Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]