h2def.py: Tudo por causa de 1 dígito…

Continuando minha saga de bindings python para bibliotecas gobject, um dos problemas que tive nos bindings da ConIC e estou tendo no OSSO-Addressbook é que o h2def.py não estava gerando as definições de objeto para cada classe existente nelas. Ou seja, eu tinha que fazer tudo na mão.

Fuçando (de novo…) o código do h2defs.py, quando ele vai procurar definições de objetos ele usa procura logo estruturas (structs) que possam “parecer” com GObjects, adicionando a uma lista maybeobjects, e em seguida procura pelas estruturas de classe desses objetos (NomeDoObjetoClass). Caso encontre as estruturas de classe, o objeto é considerado um gobject e é adicionado na lista final.

Para achar as estruturas, ele usa 2 expressões regulares, uma para estruturas do tipo

struct _NomeDoObjeto{

    ObjetoPai *parent;

    ...

e outra para estruturas do tipo:

typedef struct {

    ObjetoPai *parent;

    ...

} NomeDoObjeto;

Ao achar uma ocorrência do padrão, maybeobjects recebia uma tupla com o nome do objeto e o nome do pai, que no segundo caso estava em ordem inversa do primeiro (primeiro o pai e depois o objeto).

O problema é que na hora de adicionar o seguindo tipo a maybeobjects, acontecia o seguinte:

maybeobjects.append((m.group(2), m.group(2))

Ou seja, o nome do objeto estava sendo adicionado duas vezes, ao invés do par correto. Bastou mudar para

maybeobjects.append((m.group(2), m.group(1))

E tudo fucionou…

Documentação dos arquivos .defs do PyGTK

Esses arquivos “.defs” são gerados pelo script h2def.py, que faz parte dos scripts de geração de código do PyGTK. Eles descrevem os componentes de uma biblioteca (tipos, funções, …) baseada em gobject/glib de forma a facilitar a criação de ‘bindings’.

Por exemplo, uma função pode ser descrita como:

(function new

    (in-module (Gdk Rgb Cmap))

    (is-constructor-of GdkRgbCmap)

    (c-name gdk_rgb_cmap_new)

    (return-type GdkRgbCmap)

    (parameter in (type-and-name array-of-guint32 colors))

    (parameter in (type-and-name gint n_colors)))

Esse trecho (não está completamente atualizado…) define uma função ‘new’ que em C se chama gdk_rgb_cmap_new, é construtor do tipo GdkRGBMap, etc.

Apesar de serem bastante utilizados, até hoje não tinha achado uma fonte ‘decente’ de referência para o seu conteúdo. Isso até que olhando o código do h2def.py (sempre olhando o código…) encontrei um link para uma thread na lista de mail do gtk-devel, de janeiro de 2000, em que Havoc Pennington propõe um formato para esses arquivos. Até agora foi a descrição mais completa que encontrei, apesar de estar meio “solto”, com vários comentários.

Acho que seria uma boa idéia criar uma página no l.g.o. com essas referências…

DLSB

Bem, fazendo o teste que Walter Cruz mostrou, meus resultados foram:

  • Doer (Fazedor) – Realmente prefiro fazer uma prototipação rápida na maioria dos meus projetos.
  • Low-level (Baixo nível) – Essa deve ter ficado meio que em cima do muro. Meu dia a dia no INdT é algo “médio nível“…
  • Solo (Solitário) – … =)
  • liBeral – Citando Guido no Python Style Guide:

know when to be inconsistent — sometimes the style guide just doesn’t apply. When in doubt, use your best judgement.