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



On Sat, Aug 21, 2010 at 22:37, John Palmieri <johnp redhat com> wrote:
> 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.

Ok, we need now a volunteer :)

>> 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.

Well, packagers could still put the gio bindings in their own package
even if it's in the same tarball as pygtk. But as John Stowers is
doing the pygtk work, he knows better.

>> 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.

Apart from having code that doesn't belong in there, there's the
concern of making changes to a mature code base that won't benefit
their users.

>> > 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 http://git.gnome.org/browse/pygobject/tree/gi/overrides 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)

Johan suggested a new module called python-gnome-compat, I like it but
someone needs to go through the hoops to have it created.

Regards,

Tomeu

>
> --
> John (J5) Palmieri
> Software Engineer
> Red Hat, Inc.
> _______________________________________________
> python-hackers-list mailing list
> python-hackers-list gnome org
> http://mail.gnome.org/mailman/listinfo/python-hackers-list
>


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