PyGObject a encore pas mal de défauts je trouve qui rende son utilisation pas forcément facile :
manque de doc : la plupart du temps, il faut lire l'API C du module qu'on veut utiliser et essayer de deviner comment l'utiliser en Python. http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/index.html est intéressant mais pas suffisant, j'ai une todo-list longue comme le bras de trucs que je voudrais rajouter dedans, mais j'ai jamais pris le temps de le faire (ça c'est ma faute).
Du coup, pour les fonctionnalités de base, c'est assez facile, mais dès qu'on sort de l'ordinaire, ça devient parfois compliqué, surtout que ...
le wrapper n'est pas complet : PyGObject introduit une espèce de couche intermédiaire en Python (les "overrides") qui masque l'API C en proposant une API Python "plus agréable", comme par exemple récupérer le résultat d'un appel de fonction comme résultat de la fonction Python, et non comme un pointeur à passer à la fonction. Sauf que ces "overrides" sont fait à la main, au cas par cas, et que quand on tombe dans un cas où il n'existe pas, c'est pas joli à voir. J'ai plus d'exemple en tête, mais il faut créer des objets GVariant avec les types qui vont bien, les passer en paramètres à la fonction et récupérer le résultat dedans après...
Il y a aussi des bugs dans les bibliothèques qui fournissent les informations d'introspection, qui font ben qu'il faut attendre la prochaine version pour avoir un truc utilisable. Les mainteneurs sont assez ouverts pour rajouter un override qui va bien, sauf que ...
c'est le bordel dans les versions de PyGObject : si on veut pas se taper le boilerplate ci-dessus, on est obligé de cibler une version super-récente de PyGObject ... qui n'est pas disponible de partout : Debian testing a 11 versions de retard par exemple (Debian stable n'en parlons pas), j'avais des utilisateurs sous Gentoo qui étais obligé d'unmasker python-gobject je crois et d'autres problèmes sous Archlinux. J'ai des warnings quand je lance mon application, si je fixe mon warning ça ne marche pas avec des anciennes versions de PyGObject (j'ai dû annuler mon commit).
Au final, on se retrouve soit à ajouter du boilerplate vraiment dégeulasse et temporaire pour pallier au manque de PyGObject, soit on vise que des versions super-récentes de la bibliothèque, soit on ne fait pas (en ce moment, je fais juste pas :/ )
les performances. PyGObject et PyGtk (l'ancien wrapper statique) sont le jour et la nuit niveau performance ; sur des exemples simples (ajouter des éléments dans un Gtk.ListStore par exemple), on a des temps multipliés par 4 en utilisant PyGObject. Les mainteneurs sont au courant qu'il y a des problèmes de performance, et il y a eu plusieurs modifications dans ce sens, mais c'est pas encore assez suffisant :/
la stabilité : je sais pas si ça vient exactement de PyGObject dans ce cas là, mais j'ai eu plusieurs Segmentation Fault depuis qu'on est passé à Python 3 + PyGObject, inreproduisible, ça arrive juste comme ça. Par mauvaise conscience, j'accuserais quand même PyGobject, sans vraiment pouvoir le montrer...
Au delà de ça, je trouve la techno super intéressante, et c'est un point de passage obligé dès qu'on cible Python 3, mais à l'usage c'est pas forcément très agréable...
# Python & GObject-Introspection
Posté par jon . En réponse au journal Quelques langages de programmation pour GNOME. Évalué à 10.
Je suis mainteneur d'un projet qui utilise PyGObject (Python 3 + GObject-Introspection) et je suis pour le moment moyennement satisfait.
PyGObject a encore pas mal de défauts je trouve qui rende son utilisation pas forcément facile :
manque de doc : la plupart du temps, il faut lire l'API C du module qu'on veut utiliser et essayer de deviner comment l'utiliser en Python. http://readthedocs.org/docs/python-gtk-3-tutorial/en/latest/index.html est intéressant mais pas suffisant, j'ai une todo-list longue comme le bras de trucs que je voudrais rajouter dedans, mais j'ai jamais pris le temps de le faire (ça c'est ma faute).
Du coup, pour les fonctionnalités de base, c'est assez facile, mais dès qu'on sort de l'ordinaire, ça devient parfois compliqué, surtout que ...
le wrapper n'est pas complet : PyGObject introduit une espèce de couche intermédiaire en Python (les "overrides") qui masque l'API C en proposant une API Python "plus agréable", comme par exemple récupérer le résultat d'un appel de fonction comme résultat de la fonction Python, et non comme un pointeur à passer à la fonction. Sauf que ces "overrides" sont fait à la main, au cas par cas, et que quand on tombe dans un cas où il n'existe pas, c'est pas joli à voir. J'ai plus d'exemple en tête, mais il faut créer des objets GVariant avec les types qui vont bien, les passer en paramètres à la fonction et récupérer le résultat dedans après...
Il y a aussi des bugs dans les bibliothèques qui fournissent les informations d'introspection, qui font ben qu'il faut attendre la prochaine version pour avoir un truc utilisable. Les mainteneurs sont assez ouverts pour rajouter un override qui va bien, sauf que ...
c'est le bordel dans les versions de PyGObject : si on veut pas se taper le boilerplate ci-dessus, on est obligé de cibler une version super-récente de PyGObject ... qui n'est pas disponible de partout : Debian testing a 11 versions de retard par exemple (Debian stable n'en parlons pas), j'avais des utilisateurs sous Gentoo qui étais obligé d'unmasker python-gobject je crois et d'autres problèmes sous Archlinux. J'ai des warnings quand je lance mon application, si je fixe mon warning ça ne marche pas avec des anciennes versions de PyGObject (j'ai dû annuler mon commit).
Au final, on se retrouve soit à ajouter du boilerplate vraiment dégeulasse et temporaire pour pallier au manque de PyGObject, soit on vise que des versions super-récentes de la bibliothèque, soit on ne fait pas (en ce moment, je fais juste pas :/ )
les performances. PyGObject et PyGtk (l'ancien wrapper statique) sont le jour et la nuit niveau performance ; sur des exemples simples (ajouter des éléments dans un Gtk.ListStore par exemple), on a des temps multipliés par 4 en utilisant PyGObject. Les mainteneurs sont au courant qu'il y a des problèmes de performance, et il y a eu plusieurs modifications dans ce sens, mais c'est pas encore assez suffisant :/
la stabilité : je sais pas si ça vient exactement de PyGObject dans ce cas là, mais j'ai eu plusieurs Segmentation Fault depuis qu'on est passé à Python 3 + PyGObject, inreproduisible, ça arrive juste comme ça. Par mauvaise conscience, j'accuserais quand même PyGobject, sans vraiment pouvoir le montrer...
Au delà de ça, je trouve la techno super intéressante, et c'est un point de passage obligé dès qu'on cible Python 3, mais à l'usage c'est pas forcément très agréable...