It is all one big blur
We’ve been busy at the brmlab hacker space for a couple of days now hacking away at PyGObject Introspection. A lot of bugs have been fixed and some of the biggest GEdit plugins now works quite well thanks to Ignacio. Martin Pit has been working on porting system-config-printer which touches a lot of the Gtk+ API which he fixes as he runs into issues. Right now he is working on making GVariants easier to use. Nud has been hard at work tracking down reference counting issues which no one else wants to touch due to having to deal with two ref systems and a garbage collector. Simon Schampijer is working on Gdk issues and is readying a patch to fix places where we don’t quite get constructors correct. Sebastian is porting gnome-dvb and Tomeu is unbreaking Cairo in PyGI after the Gtk+ guys decided to wrap Cairo structs in full boxed types. Lazlo is adding annotations to Gtk+ and reviewing some of the annotations in Pavel’s gobject-introspection branch. I’ve been working on the new PyGI invoke branch which has been going really well but most likely won’t be ready to swap over until after the hackfest.
One of the greatest things about the hackfest is getting the PyGI developers familiar with debugging some of the harder areas of the library. After this is over in a few more days everyone will go home with a greater knowledge of the different bits that make up the PyGI infrastructure. This means we can start to accelerate porting and bug fixing of a few apps up to the release of GNOME 3 and then be in a good place to move everything over in the next cycle.
Thanks goes to Collabora for funding our beers which puts us to sleep so we can wake up refreshed the next morning. The Collabora thank you dinner will be happening tomorrow night. Also, thanks to the Foundation for giving us the infrastructure for organising such events. I plan on writing something less formal than the current guidelines so other people can use as another reference to organizing similar events. BTW, any hackers near Prague should check out the hackspace. We need one of these in every city there is FOSS developers.
Great news, guys!
But what about making PyGi more python-ic? I think it would be very important to follow PEP8 here!
Keep on with your great work! Thanks,
Sebastian
Comment by sbillaudelle — January 19, 2011 @ 6:36 am
@sbillaudelle
We try to follow the style guidelines where legacy doesn’t dictate one way or another. Feel free to file bugs or even patches in place we do not.
Note that in some cases we are doing things (like exception handling) in a way that supports both Python 2 and 3. Also note that GI itself has some attribute styling that we feel is more important to keep for moving between different GI languages (not to mention it is faster not to convert them). I think for the most part they are similar to the Python guidelines but I haven’t really looked into it.
Comment by J5 — January 19, 2011 @ 7:24 am
Thanks for your reply!
I started a discussion on that some month ago on your mailinglist. And it seemed that most people agreed, that having Python-styled constants and imports would be the way to go.
For example “from gi.repository import gtk” instead of “from gi.repository import Gtk” or “gtk.FOO_BAR” instead of “gtk.FooBar”.
Following those guidelines is one of the key criterias to a lot of Python devs I know. Its one of the reasons some don’t like to use PyQt.
As stated in http://live.gnome.org/GObjectIntrospection/HowToWriteALanguageBinding, following the languages’ styling guides would be desireable!
If you’re interested, you may take a look at the original discussion: http://mail.gnome.org/archives/python-hackers-list/2010-October/msg00004.html
Do you think it would be a good idea to open a bug report on this? Or would it be possible to take those points into consideration without a bug report?
(Sorry for my bad English. I’m not a native speaker and don’t have that much time at the moment to re-read my post…)
Thank you very much and have a great time in Prague!
Comment by sbillaudelle — January 19, 2011 @ 11:24 am
It was discussed and we aren’t going to change the case of the module. In this case it makes it much easier for porters to spot issues and it avoids name clashes with static modules.
> “gtk.FOO_BAR” instead of “gtk.FooBar”
We do this for constants, flags and enums though classes that these come from are camel cased:
e.g. Gtk.FooEnumType.BAR_BAZ
We wanted to get away from polluting the Gtk namespace with things like Gtk.FOO_ENUM_TYPE_BAR_BAZ
I believe that objects and functions follow the PEP so a majority of the code shouldn’t be so foreign.
w = Gtk.Window()
w.set_title(”hello”)
w.show()
Gtk.main()
Comment by J5 — January 20, 2011 @ 6:55 am
Thanks for that clarification!
I think I’ll be able to live with that;)
Thanks again for your reply!
Comment by sbillaudelle — January 20, 2011 @ 4:36 pm