Agora sim, chega de trabalhar na moitinha igual contra-regra, o negócio agora é público: PySide foi lançado!
Sim! E o que é PySide, você pergunta? São bindings da biblioteca Qt4 para linguagem Python criados pelo INdT e a Nokia (Moi, tamperelaiset!) sob licença LGPL. Minha equipe (não sou dono dela, minha no sentido de “nossa sem incluir o interlocutor”) trabalhou feito louca e o lançamento foi uma beleza: tivemos um retorno positivo da comunidade e as notícias estão aparecendo em toda parte.
E fornecemos não apenas o peixe mas também a vara (na boa): o gerador de bindings também está disponível. Mas qual a importância disso? Dada a notícia vou explicar com calma.
Antes de continuar repare na garrafinha de Prince of Persia no logo do PySide. É a marca usada em projetos do Qt Labs Americas.
Os Bindings
O motivo primário da criação do PySide foi prover bindings Python da Qt4 sob a licença LGPL, para se alinhar com a oferta da Nokia da própria Qt4. Várias possibilidades de como fazer foram analisadas, e antes dessa frase começar uma discussão técnica infinita, todas as opções tinham pontos bons e ruins, mas não tão diferentes assim. A idéia do Smoke foi uma das que mais gostamos e vale uma menção. No fim optamos por alterar um gerador de bindings existente (mais sobre isso abaixo) e usar o Boost.Python para fazer meio-campo com a API CPython. Trocando em diagramas coloridos esse é o PySide:
O Gerador
Escrever bindings pra uma biblioteca tão massivamente grande quanto Qt é uma tarefa… não, não é uma tarefa, é uma punição. Pessoas de bom senso que somos demos uma pesquisada por aí e optamos por adaptar o código do QtScript Generator, que por sua vez é um fork do Qt Jambi Generator, e ambos são geradores de bindings QtScript e Java, respectivamente, desenvolvidos pela Trolltech (quando ela se chamava Trolltech).
O esquema de geração de bindings funciona assim:
O arquivo global.h inclui todos os headers (pelo menos os desejados) da biblioteca sendo processada, e também define e desdefine flags do preprocessador. Arquivos typesystem.xml são descrições de como a biblioteca deve ser exportada para a linguagem alvo: classes rejeitadas, métodos renomeados, tipos convertidos e, muito importante, códigos escritos à mão para casos especiais e onde eles devem ser inseridos. Se não houver necessidade de alterações esse xml será apenas uma simples lista de classes, enums e funções.
Notem que não apenas forkamos o QtScript Generator, mas a convertemos de uma aplicação monolítica num esquema lib (que chamamos de API Extractor) + front-end gerador. E mais uma figura pra explicar a idéia:
Teoricamente os projetos dos quais derivamos código poderiam ser alterados para usar o API Extractor e compartilhar essa base de código (e bugs, e fixes, e melhorias). Além disso, o sujeito pode escrever front-ends que gerem outras coisas que não código: grafos de relacionamento entre as classes, estatísticas, algo-que-eu-não-pensei.
Agora a parte não tão bela. Num mundo perfeito o gerador de bindings C++ para Python geraria bindings de qualquer biblioteca C++ para Python, contudo da forma que se encontra agora o gerador serve apenas para bibliotecas baseadas em Qt. Grande vergonha! Considerando que o foco era criar o bindings Qt e os lançamos em versão beta, sugiro nos perdoar. 🙂 Claro que está nos planos resolver isso e tornar o gerador uma ferramente genérica e útil para mais pessoas.
Informação demais! Por hora, baixem, testem, relatem bugs e aproveitem. E se estiverem se sentindo sociais entrem no canal #pyside no FreeNode e assinem a lista de discussão.
Setanta's Place 
gosto que teus diagramas, mesmo muito coloridos, são daltônico-friendly.
e porque o nome? uma jogada de marketing meio “come to the PySide of the force”?
obrigado, gosto de exagerar nas cores 😀
sobre o nome “Side” vem do finlandês para bindings, mas a sua interpretação é realmente inevitável 🙂
Gostei da iniciativa, mas afinal, além da licença que no PyQt é GPL2, existe mais algum diferencial entre o PySide e o PyQt?
Pelo que li vocês mantiveram compatibilidade entre o PyQt e o PySide, o que achei muito bom. É intenção manter assim?
Um incômodo no PyQt é a ausência das docstring. Ainda não teste o PySide, mas existe alguma intenção em manter/adicionar as docstrings?
Show de bola Marcelo, realmente deve ser legal poder trabalhar com QT no lado de “desenvolver a api”
🙂
@jorgepereira: sim, é legal. ruim é que programo mais C++ que Python faz meses.
@Rudson: o principal diferencial é a licença. algo menor que poderia citar é o processo de geração dos bindings que é um pouco diferente, mas isso é colateral. Embora tenhamos a intenção de continuar provendo a API como está estamos empolgados mesmo com a possibilidade de integrar melhor com Python. Vamos discutir o máximo possível publicamente sobre essa versão pythonica. No momento não colocamos docstrings por questões de tamanho, mas temos planos pra elas.
Mais algumas questões Marcelo:
– O PySide está rodando em 64bits?
Não consegui compilá-lo em meu Slackware64. O apiextractor e o boostpythongenerator foram bem, mas o PySide deu erro na hora de compilar o abstract_qobject_connection.cpp.
– E sobre a lista, ela não manda mensagem de confirmação?
Desculpe a perturbação, mas o projeto me parece interessante.
@Rudson, não perturba nada, rapaz, o bom é que todo mundo use e relate problemas mesmo. Na equipe do PySide nós buildamos em Ubuntu e Arch Linux, ambos 64bits, e tudo vai bem.
Seria melhor mandar seu problema (e as mensagens de erro) pra lista do PySide[1] (alguém pode ter uma resposta na ponta da língua), mas pelo que você falou sua inscrição na lista deu errado. Mande um email pra mim[2] com seu próprio email que posso ver qual o problema e se preciso te incluo na lista manualmente.
[1] http://lists.openbossa.org/listinfo/pyside
[2] marcelo.lira@openbossa.org