The PySide of the moon: la fine di PyQt?

dark_side

Oggi durante un pomeriggio afoso e un po’ noioso è arrivato un tweet contenente due tags di mio interesse: Python e Qt. Seguito il link al sito vengo a conoscenza di PySide, un’implementazione di bindings Python con licenza LGPL; leggo questa frase e subito penso distrattamente a PyQt che non ha seguito le orme di Nokia ed è rimasta su un modello dual licensing. Mentre scorro rapido le pagine del sito di PySide mi immagino il progetto come l’iniziativa un po’ velleitaria di qualcuno cui farebbe comodo una licenza meno restrittiva per PyQt, eppure a fondo pagina campeggiano dei logo di marchi piuttosto importanti, primo fra tutti Qt: quel logo sarà autorizzato?

Leggo le FAQ e scopro che sì, Nokia ha le mani in pasta nel progetto. Non solo, sempre dalle FAQ scopro che Riverbank è stata contattata da Nokia in un primo momento, ma non c’è stato l’accordo per una eventuale collaborazione, e siccome Nokia i mezzi ce l’ha, sta portando avanti il progetto con risorse interne.

A questo punto è chiaro che PySide non è un progetto da Summer of Code: a Nokia servono i bindings Python e si è messa a produrli. Come e quanto il progetto danneggerà PyQt?

Dal sito si apprende che l’API verrà mantenuta 100% compatibile con quella di PyQt (almeno in un primo momento); questo significa che per migrare del codice esistente basterà cambiare le direttive di import, rendendo di fatto gratuita l’operazione, fosse anche per soli scopi di valutazione del prodotto.

Ho già accennato alla licenza e sebbene personalmente trovi buono il modello di PyQt e ragionevoli i costi delle licenze commerciali, devo ammettere che trovo migliore la scelta fatta da Nokia per Qt e di conseguenza per PySide: LGPL. Nella mailing list di PyQt è stato chiesto al lead developer one-man-band di PyQt, Phil Thompson, come intendesse comportarsi a seguito della scelta di Nokia di abbandonare la QPL: una risposta chiara non è mai arrivata è arrivata solo dopo alcune settimane, ma non è difficile immaginare che gli introiti delle licenze commerciali di PyQt siano aria fresca per la Riverbank.

Sip, il tool usato dalla Riverbank per la produzione di PyQt è ad oggi l’unico in grado di generare bindings di codice Qt out of the box. Sebbene praticamente privo di documentazione, una volta presa la mano difficilmente sbaglia il colpo. Su questo fronte la Riverbank sembra un po’ più avanti, infatti l’omologo di sip per PySide, boostpythongenerator, presenta alcune limitazioni dovute a dipendenze da Qt che non lo rendono adatto alla generica produzione di bindings Python. Purtroppo per Riverbank però la situazione evolverà a breve nell’ottica di rendere il tool il più generico possibile, col rischio di farne uno strumento diffuso…

In definitiva, al momento non ho gli strumenti per giudicare la bontà di PySide non avendolo provato; di certo il patrocinio di Nokia fa pensare che lo scopo sia farne lo strumento ufficiale per gli sviluppatori Qt che lavorano in Python. Nel frattempo nella mailing list di PyQt tutto tace…

6 thoughts on “The PySide of the moon: la fine di PyQt?

  1. Bella li` Masci, questa e` una notizia da prima pagina!

    Leggendo un po’ qui e la` per il sito di PySide ho anche avuto un po’ la sensazione che vogliano puntare ad un processo di sviluppo un po’ piu` aperto verso i contributi e interventi di una potenziale comunita`, cosa che la Riverbank – dovendo mantenere un copyright esclusivo – probabilmente non e` mai stata in grado di fare..

  2. Bella notizia davvero masci.
    E comunque concordo con te, si tratta solo questione di tempo: Nokia ha sicuramente i mezzi per fronteggiare/scavalcare PyQt.

    @Qzerty: intendi un progetto “open” al 100% con supporto della comunità?

  3. @Marco: beh, non e` che gli possa leggere nel pensiero, ma questo e` quello che scrivono: “Getting more and more people involved with a project is the first step to build a community. But people will stay together only if they believe in that project. PySide tries to keep everything as open as possible and wants to share the same way of life with its developers.”. E anche “While the PySide project has been initiated and the first set of code provided by Nokia, PySide will be run as a true open source project. Nokia will provide multiple developers working on the project, but contributions will be encouraged and the contributors need not transfer their copyright or accept a code reuse license; merely providing code under the LGPLv2.1 license will be sufficient.”

    Ora come ora la mia impressione e` che la motivazione per dei nuovi bindings non sia tanto nella necessita` di una differente implementazione (dietro la stessa API o un’interfaccia piu` Pythonic), ma proprio di avere a che interagire con un progetto piu` aperto e basato su un licensing piu` liberale.

  4. dunque, premetto subito che non sono un programmatore (neanche un tecnico informatico) e non capisco un’acca di Python. Perché scrivo qui, allora? Semplicemente perché ci sono arrivato trasversalmente (tramite il roll-blog di G. Sforna, per la precisione) e pochi minuti prima avevo notato sia PyQT sia SIP fra gli aggiornamenti ‘ufficiali’ della mia Fedora 10 (il sistema operativo che utilizzo stabilmente da 3 anni). Da quanto detto all’inizio, non sono minimamente in grado di valutare se questo fatto incida, e in quale misura, sui problemi di cui discutete qui, però mi sembrava utile portare questo pezzetto di informazione; magari non utilizzate Fedora e questo potrebbe essere un indizio interessante di cui non eravate a conoscenza.
    Altrimenti scusate l’intrusione e buon proseguimento. CIAO

  5. devo ammettere che la recente novita` relativa al fatto che stiano reimplementando il generatore di bindings per disfarsi di Boost.Python e` stata un po’ una doccia fredda e mi ha messo la maturita` del progetto sotto tutt’altra luce.. non che abbia da ridire sulla possibilita` che Boost.Python non sia poi cosi` adatto (non ho mezzi per esprimere un giudizio di prima mano), ma non mi pare un dettaglio secondario..

Comments are closed.