Risorse Python: aggiornamento 9 - Editor e IDE per sviluppare in Python

Prima o poi il codice Python con qualcosa bisognerà pure scriverlo. Massiccio aggiornamento della sezione risorse Python con l'aggiunta di due intere sottosezioni dedicate all'argomento:

• Editor per Pyhon
• IDE per Pyhon

Aggiunto anche un tutorial interattivo di Codecademy per Python 2.x.

Come e perché usare il versioning semantico

Avete presente tutti quei numeri che indicano la versione di un certo software? Parlo di quei numeri del tipo x.y.z. Per esempio Python al momento in cui scrivo esiste nella versione 2.7.8 e 3.4.1.

Vi siete mai chiesti cosa rappresentano e come vengono decisi quei numeri?

Si tratta del cosiddetto versionamento semantico o semantic versioning. In poche parole:

• X rappresenta la "major" release di un software, ossia una release la cui API (Application Programming Interface) non è retrocompatibile con la precedente release. Python 3.x ha un'API non retrocompatibile con quella di Python 2.x, per esempio lo statement print è diventata la funzione print();
• Y rappresenta la "minor" release di un software, ossia una release in cui anche se vengono aggiunte nuove funzionalità, l'API  resta retrocompatibile con la versione precedente del software.
  Python 2.7 ha aggiunto/modificato delle funzionalità, ma queste sono retrocompatibili con la precedente versione Python 2.6, perciò il software che avete scritto per la 2.6 continuerà a girare anche con Python 2.7;
• Z rappresenta laa "patch" release di un software, ossia una release in cui vengono solo corretti dei bug e l'API  resta comunque retrocompatibile con la versione precedente del software.
  Python 2.7.8 è una versione che corregge dei bug rispetto alla precedente 2.7.7 e resta retrocompatibile con essa.

Perché usare il semantic versioning? Per evitare (o almeno provare ad evitarlo) il "dependency hell", l'inferno delle dipendenze.

Immaginate di avere un vostro software che usa la versione X.Y.Z , per esempio la 2.1.0 di un certo modulo/liberia sviluppata da qualcun altro: se il suo sviluppatore segue il versioning semantico, potrete avere una ragionevole sicurezza che non ci saranno modifiche non retrocompatibili finché userete il ramo 2.X di quel modulo.

Allo stesso modo, quando sviluppate voi un software, potete comunicare in modo semplice ed efficace che tipo di modifiche avete fatto:

• se è un semplice bugfix modificherete il numero Z di patch release, ad esempio da 2.1.0 a 2.1.1;
• se avete aggiunto nuove funzionalità senza però rompere la retrocompatibilità, modificherete solo il numero Y di minor release, ad esempio da 2.1.1 a 2.2.0;
• se la vostra nuova versione del software ha un'API non più compatibile con quella delle versioni precedenti, modificherete il numero X di major release, ad esempio da 2.1.1 a 3.0.0.

Se ancora non state usando queste convenzioni nello sviluppo del vostro software e vi siete incuriositi almeno un po' alla questione, allora leggete il resto della storia sul versionamento semantico.