merging PyGI into PyGObject


Johan has suggested merging PyGI back into PyGObject because:

- PyGI has reached "useful" status, applications that make use of it are packaged and used in distros and we are close enough to being feature-complete.

- PyGI is more mature now: is regularly maintained, uses the GNOME infrastructure, is packageable, code contributions are reviewed, has consistent code guidelines, etc.

- some of the biggest features missing in PyGI overlap with functionality already in PyGObject, namely properties and signals. If we want to be able to support properties that return collections and do so with proper memory management, we need to be able to use the information available through introspection. If we tried to implement this in PyGI, we would be duplicating lots of work currently in PyGObject.

- some changes are needed in the GType system for supporting fundamentals and foreign structs coming from g-i.

It has been proposed as well making the --enable-pygi switch the default.




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