Installare e usare Python su Windows (parte 8/10).

Attenzione!

Queste guide non sono più aggiornate, e in alcuni punti sono proprio superate.
Il mio libro Python in Windows tratta questi temi, e molto altro, in modo molto più completo e aggiornato. 

Tool per programmare.

Gli strumenti di lavoro del programmatore sono infiniti, e ciascuno nel tempo sviluppa le sue preferenze e le sue antipatie. In questa sezione elenchiamo solo alcuni strumenti indispensabili, o quasi.

ConEmu: console emulator.

Arrivati a questo punto, avrete ormai notato che la shell è uno strumento indispensabile e onnipresente per programmare (e non solo in Python). Avrete anche notato che la shell di Windows cmd.exe è particolarmente scomoda. Non potete fare a meno di un “console emulator”, e ConEmu è il migliore in circolazione per Windows. ConEmu è un software complesso ma a voi basterà conoscere le basi. ConEmu è un manager in grado di gestire diverse shell contemporaneamente (cmd.exe, PowerShell, ma anche Git Bash come vedremo) e di offrire alcuni servizi aggiuntivi come font, colori, etc. Uno dei molti vantaggi di ConEmu è la facilità con cui potete aprire una shell in modalità “privilegiata” (ovvero con privilegi da amministratore), cosa che come abbiamo visto può tornare utile per installare pacchetti nel Python 3 di sistema, per settare variabili d’ambiente in modo permantente, etc.
È preferibile installare ConEmu nella sua versione potenziata Cmder, che oltre a ConEmu include anche Clink (che emula le funzionalità di GNU Readline, e offre shortcut aggiuntivi). L’installer di Cmder, volendo, comprende anche Git for Windows: è tuttavia preferibile installare Git separatamente, come vediamo qui di seguito.

Git: version control system.

Da qualche anno GitHub è diventato un modo molto popolare di pubblicare il proprio codice, condividerlo, cercare collaborazioni, farsi conoscere. Anche se non avete intenzione di aprire un account su GitHub, probabilmente vi conviene comunque usare un sistema di controllo di versione (VCS) per i vostri progetti, e Git è ormai di gran lunga il più popolare. Non è questa la sede per descrivere che cosa è e a cosa serve un VCS: la documentazione di Git fa un buon lavoro anche a spiegare la filosofia e le strategie d’uso più comuni.
Per installare Git su Windows, avete due possibilità. La prima è GitHub Desktop, una interfaccia grafica progettata per semplificare la gestione delle repository su GitHub, ma che si può usare anche solo in locale. È un software molto piacevole e intuitivo da usare, ma non è la nostra prima scelta. Dopo tutto, Git è nato come uno strumento di lavoro snello, che si governa con la shell: i comandi più comuni, poi, sono davvero semplici da usare. L’interfaccia grafica può sembrare più accattivante, ma alla fine appesantisce un po’ l’uso di Git, tutto sommato senza buone ragioni. Inoltre molti editor ormai offrono qualche tipo di integrazione con Git, e quindi userete Git quasi sempre dal vostro editor.
Il nostro consiglio è invece di installare Git per Windows uno strumento più snello che comprende, oltre a Git, la shell Git Bash (un porting della nota shell Unix Bash), l’interfaccia grafica GitGui (abbastanza comoda da usare, se proprio volete restare lontani dalla shell) e il “commit viewer” GitK (utile per avere una rappresentazione grafica dell’albero dei commit, per esempio).
Al momento di installare Git per Windows, potete scegliere tra le numerose opzioni quelle che vi sembrano più opportune. Vi consigliamo in particolare di selezionare “Use Git from Git Bash only”, dal momento che Git Bash è una shell molto più completa del solito cmd.exe (molti installano Git anche solo per avere Bash!), e vi conviene abituarvi ad usarla per tutte le vostre operazioni, e non solo quelle con Git. Quando poi si arriva alla scelta della console, è indifferente selezionare “Use Windows’ default console window”, oppure scegliere MinTTY: la verità è che comunque useremo Git Bash all’interno di ConEmu che abbiamo già installato, senza ricorrere né a cmd.exe né a MinTTY. Se però non avete ConEmu, allora usate senz’altro MinTTY. Infine, ricordatevi di selezionare “Enable Git Credential Manager” specialmente se avete intenzione di usare Git per collegarvi a un server come GitHub.
Completata l’installazione, potete usare GitGui per le operazioni sulle vostre repository Git, se preferite. Ma probabilmente la cosa più rapida è lavorare con Git Bash, con qualche occasionale sguardo a GitK. Vi conviene usare Git Bash all’interno di ConEmu, chiaramente. La cosa migliore è registrare un nuovo task in ConEmu (“Win+Alt+T”, poi “Add default task”) che potete chiamare “Bash” e dovrebbe avere un comando come:

"C:\Program Files\Git\bin\sh.exe" --login -i -new_console:d:"d:\repos"

Notate che è importante selezionare il corretto eseguibile ...\Git\bin\sh.exe, e assolutamente non git-bash.exe che avvia Bash in un terminale suo proprio (cmd.exe o MinTTY a seconda di cosa avete scelto installando Git). Come directory di partenza vi conviene scegliere la directory base dei vostri progetti (d:/repos nel nostro caso).
Una volta avviata la shell Bash, potete portarvi nella directory del progetto che vi interessa e dare il comando git init per creare lì una repository Git. Il prompt (master) vi indicherà a questo punto che siete nel branch di default master. Giocare con Git dalla shell a questo punto è facile. Provate per esempio:

(master) $ git checkout -b devel
Switched to a new branch 'devel'

(devel) $ touch README.rst LICENSE NEWS requirements.txt

(devel) $ git status
<...>

(devel) $ git add -A

(devel) $ git commit -m "initial"
<...>

(devel) $ gitk

Se invocate gitk mentre siete in una repository, aprite l’interfaccia grafica di GitK e potete vedere i vostri commit (naturalmente potete usare anche git log per questo).

Jupyter Notebook: shell interattiva.

L’interprete interattivo dei comandi Python (la shell con il caratteristico prompt >>>, per intenderci) è uno strumento essenziale non solo per le piccole necessità di tutti i giorni, ma anche quando siete immersi in un progetto “importante”. La shell vi consente di provare rapidamente frammenti di codice, verificare la documentazione, importare ed eseguire interattivamente il codice che state scrivendo, e così via.
Non c’è niente di male nell’invocare l’interprete Python direttamente nella vostra shell, come abbiamo fatto finora: è il modo più rapido, e spesso è più che sufficiente. Tuttavia per le sessioni più lunghe e impegnative desiderate avere un’interfaccia migliore. Le opzioni non mancano, a partire da IDLE, la shell di default che trovate installata con Python. Potete avviare IDLE dai link del Menu Start, naturalmente. Ma forse a questo punto preferite usare la shell:

> py -m idlelib

In questo modo potete avviare le diverse IDLE “globali” (con py -2 -m idlelib, py -3 -m idlelib etc.) oppure, se siete all’interno di un venv, la IDLE del venv.
Un’altra opzione è costituita dal vostro editor. Molti editor evoluti offrono la possibilità di integrare una REPL per vari linguaggi di programmazione, tra cui naturalmente anche la shell di Python. In genere potete configurare la shell integrata per lavorare globalmente, oppure all’interno di un venv.
Tuttavia in questi anni si è progressivamente affermata una shell molto evoluta e ricca di opzioni: gli Jupyter Notebook (in precedenza noti come IPython Notebook) sono lo stato dell’arte, al punto che è riduttivo considerli solo delle shell. Jupyter è piuttosto un ambiente di sviluppo (IDE) interattivo, rivolto soprattutto alla comunità scientifica e alle applicazioni di data visualisation. Il sito è ricco di esempi e la documentazione è molto completa. Potete provare i notebook nel vostro browser senza installare nulla, se volete farvi un’idea.
Il sito ufficiale raccomanda di usare i notebook Jupyter installando Anaconda, una distribuzione di Python dedicata soprattutto all’ambito scientifico che comprende moltissimi pacchetti pre-installati tra cui, appunto, anche Jupyter. Ma non è assolutamente necessario installare Anaconda per usare i notebook Jupyter. Potete installare Jupyter semplicemente con Pip: pip install jupyter è tutto ciò che serve. Siccome Jupyter ha bisogno di moltissimi altri pacchetti, è consigliabile installarlo in un venv appositamente creato, per poterlo valutare senza impegno. Se vi piace, potete successivamente installarlo nel Python di sistema. Non è pensabile installarlo in ciascun venv di progetto, naturalmente: potete però renderlo disponibile ai venv con l’opzione --system-site-packages di cui abbiamo già parlato.
Una volta installato Jupyter, avete due opzioni principali per avviarlo. Potete invocare dalla shell jupyter console per aprire un notebook con l’interfaccia testuale direttamente nella shell. Oppure potete invocare jupyter notebook per aprire un notebook nel vostro browser, e sfruttare tutte le opzioni che vi offre l’interfaccia grafica. Le possibilità dei notebook Jupyter sono impressionanti: leggete la documentazione online per farvi un’idea.

Scegliere un editor.

Come abbiamo già avuto occasione di dire, non si può scrivere codice con il Blocco Note o (addirittura!) con Word. Dovete imparare a usare un editor “intelligente” di file di testo. La scelta di un editor dipende da mille fattori, è sempre molto personale, e la rete è piena di discussioni interminabili su qual è il “miglior editor”. Ci limitiamo qui ad alcune considerazioni e suggerimenti molto generici.
In primo luogo, è sempre più difficile distinguere tra un "IDE" e un "editor". In teoria un IDE è un ambiente integrato che comprende, oltre all’editor vero e proprio, molti altri strumenti (debugger, compiler, code completion, integrazione con vari framework, version control system, e altro ancora); un editor d’altra parte è “solo” specializzato nella scrittura del codice, e offre funzionalità più mirate al codice in senso stretto, e non allo sviluppo di applicazioni in senso più ampio. In pratica però tutti gli editor più importanti possono essere ampliati con estensioni di vario tipo che aggiungono funzionalità, fino a trasformarli in veri e propri IDE. Di contro, è possibile disattivare molte funzionalità non necessarie di un IDE, fino a usarlo quasi come un editor. È vero comunque che un IDE tende a “imporsi di più” sul lavoro che fate: per sfruttarlo al meglio dovete accettare un po’ di sovrastruttura necessaria. Un editor, per contro, di solito è più snello e non impone nessun particolare modo di lavorare. D’altra parte, gli IDE “all inclusive” possono essere più facili da usare e configurare; un editor invece potrebbe essere quasi inutilizzabile così com’è, e aver bisogno di un lungo processo di configurazione per lavorare come serve a voi.
Ma tutte le differenze sono opinabili, e per ogni generalizzazione ci sono sempre dieci contro-esempi. Scegliete con calma l’editor o l’IDE che si adatta di più al vostro modo di lavorare e al vostro gusto.
In primo luogo, il già menzionato IDLE comprende oltre alla shell interattiva anche un editor. In genere non sono molti quelli che continuano a usare IDLE dopo i primi esercizi. IDLE è inteso come ambiente di lavoro provvisorio e spartano per chi, dopo aver installato Python, desidera mettersi subito al lavoro. Anche se all’inizio potrebbe piacervi proprio per la sua semplicità, probabilmente è meglio investire fin da subito in un editor più completo, in grado di supportarvi mentre progredite nella vostra conoscenza di Python.
A parte IDLE, il primo editor che dovreste prendere in considerazione è Vim: è un editor concepito per girare direttamente nella shell, senza interfaccia grafica. È estremamente potente e flessibile, ed è l’editor preferito da molte “star” della programmazione. Ha una vasta e vocale “fan base” pronta a sostenere che sia il miglior editor possibile. La verità è che è anche un editor difficile da imparare e difficile da configurare. Si può scaricare e installare una versione dotata di interfaccia grafica (gui): ma nessuno sostiene che la gui di Vim sia competitiva con quelle dei moderni editor come Sublime Text o altri. Vim è fatto per essere usato nella shell, senza il mouse, i menu a tendina e le altre piacevolezze grafiche a cui siamo abituati. Molti programmatori però lavorano proprio in questo modo, senza mai uscire dalla shell (o meglio, dall’emulatore di terminale che comprende la shell). Se il vostro lavoro si svolge tutto o quasi nel terminale, allora probabilmente Vim è davvero il vostro editor (ma potreste voler dare un’occhiata anche a Emacs prima di fare una scelta definitiva).
Tuttavia, anche se Vim non è il vostro editor preferito, è comunque obbligatorio imparare e memorizzare almeno i pochi comandi fondamentali che vi permettono di aprire un file, apportare delle modifiche, salvare e uscire. Infatti ci sono alcune occasioni in cui Vim è davvero tutto quello che avete: per esempio se usate Git, quando dovete scrivere un messaggio di commit Git Bash apre Vim per voi (questa può essere una sorpresa… interessante, la prima volta che capita). Oppure, quando vi collegate a un server remoto con una connessione ssh, Vim è praticamente l’unica cosa che siete sicuri di trovare, e che funziona in una shell, se volete anche solo aprire e leggere un file. Infine va detto che Vim, con tutte le sue peculiarità, è comunque lo strumento più comodo quando dovete modificare al volo un file, senza bisogno di abbandonare la shell e aprire un editor separato.
Se avete installato Git for Windows e quindi Git Bash, avete già anche Vim. Portatevi in una directory in cui c’è un file di testo, e apritelo con Vim:

$ vim miofile.txt

…e adesso la domanda è: come faccio a uscire? Ecco perché occorre imparare almeno le basi di Vim! (Suggerimento: premete in sequenza <esc>:wq<invio> per salvare le modifiche e uscire, o <esc>:q!<invio> per uscire senza salvare).
Se preferite un editor grafico o un IDE, allora la scelta non manca. Il boss degli IDE è sicuramente Eclipse da usare con i tool specifici per Python di PyDev. Si tratta della “esperienza IDE” per definizione, completa e totalizzante, che integra e supporta ogni aspetto della vostra attività di programmatore. Il vantaggio è che non resta nulla o quasi che dovete cercare altrove. Lo svantaggio, probabilmente, è che vi sentirete un po’ costretti a fare le cose solo in un certo modo. È davvero una questione di gusti, alla fine. Da un punto di vista tecnico, considerate solo che Eclipse/PyDev è esigente in termini di richieste di sistema: se amate programmare in treno tenendo il sub-notebook sulle ginocchia, allora Eclipse potrebbe non essere lo strumento giusto per voi.
Tra gli IDE “corposi”, la principale alternativa a Eclipse/PyDev è PyCharm: sembra che in questi anni stia prendendo il sopravvento su Eclipse in termini di popolarità, quindi forse vorrete dare un’occhiata prima a questo. Un’alternativa ulteriore potrebbe essere WingIde (la cui versione free è tuttavia piuttosto limitata).
Parlando di IDE in Windows, non possiamo certo trascurare Visual Studio. La corazzata di casa Microsoft ha fatto negli ultimi anni due passi importanti che l’hanno resa competitiva anche al di fuori del mondo .Net e per la programmazione Python nello specifico: Visual Studio Community, una versione free dedicata espressamente al mondo dell’open source, e i Python Tools per Visual Studio, sviluppati dal Python Team di Microsoft (guidato da Steve Dower, che è anche l’esperto Windows tra i core developer di Python, e il responsabile delle Windows release di CPython). È difficile paragonare punto-a-punto Eclipse/PyDev e Visual Studio/Python Tools: sicuramente se siete interessati anche allo sviluppo .Net, allora Visual Studio dovrebbe essere lo strumento che fa per voi.
Se gli IDE vi sembrano troppo ingombranti e preferite un editor grafico più snello, allora davvero avete l’imbarazzo della scelta. Ce ne sono talmente tanti che spesso è solo una questione di mode passeggere: per esempio negli ultimi anni Atom e Brackets hanno preso quota; ma nel mondo Windows Notepad++ resta sempre uno dei più popolari.
Ma il primo della classe nel campo degli editor grafici è probabilmente Sublime Text: vanta una larga e attiva comunità di utenti, e una repository sterminata di add-on che coprono praticamente qualsiasi necessità. Sublime Text ha introdotto o reso popolari molti concetti innovativi come l’editing multi-cursore, che poi sono stati emulati dagli editor grafici più giovani. In effetti, editor come Atom o Brackets hanno un’aria… molto familiare per chi è abituato a Sublime Text. Un pregio ulteriore di Sublime Text è la sua notevole velocità e robustezza: è difficile vedere un crash o un rallentamento anche con file di notevoli dimensioni. In generale, Sublime Text è forse l’unico editor grafico che non fa storcere il naso neppure alla “vecchia scuola” degli hacker che usano Vim o Emacs. Il lato negativo è che è un po’ difficile da configurare, e la sovrabbondanza di add-on rende complicato scegliere. Se volete usare Sublime Text per la programmazione Python, vi conviene prendere spunto da una guida come questa.
Prendiamo infine in considerazione Visual Studio Code, un editor di Microsoft ancora giovane, ma che è già cresciuto rapidamente e si è conquistato una sempre crescente quota di successo. Nonostante il nome, non ha niente a che vedere con Visual Studio. È basato sul motore Node.js Elektron, cosa che lo rende parente stretto di Atom; e come Atom, è evidententemente ispirato a Sublime Text. È tuttavia più veloce e stabile di Atom, e rispetto a Sublime Text sembra un po’ meglio organizzato, più facile da usare. Chiaramente non può competere con Sublime Text in velocità e nella quantità di stili e add-on disponibili. Se siete programmatori esperti e avete già delle esigenze particolari, Sublime Text è ancora imbattibile (e forse lo resterà per molto tempo). Se state iniziando, Code potrebbe essere uno strumento interessante: relativamente stabile, veloce, facile da usare, in rapida crescita e con un buon supporto da parte di Microsoft. E in definitiva, una volta imparato Code è comunque molto facile passare poi a Sublime Text.
Aggiungiamo qualche indicazione su come usare Code per la programmazione Python. Con questo non intendiamo suggerire che Code sia l’editor migliore: è solo facile da impostare, e quindi adatto a una breve guida come questa, per dare l’idea di cosa più o meno occorre fare anche con gli altri editor. Prima di tutto, bisogna scaricare e installare Code. Fatto questo, occorre procurarsi l’estensione ufficiale per Python. Potete installarla direttamente da Code: cliccate sul pulsante “Extensions” nella barra a sinistra (o usate la shortcut Ctrl+Shift+x), cercate “Python” (per riconoscerla, ricordate che è distribuita dalla stessa Microsoft) e installate. Il manuale completo si trova qui.
Code ha la nozione di “spazio di lavoro” (workspace), che corrisponde a una directory: usate quindi “Open folder…” per aprire uno spazio di lavoro e il pulsante “Explorer” della barra a sinistra per vedere i file della directory. Potete regolare le impostazioni generali (File -> Preferences -> User settings…), e le impostazioni specifiche per lo spazio di lavoro (File -> Preferences -> Workspace settings…). Le impostazioni dello spazio di lavoro sovrascrivono le impostazioni generali: Code genera una directory nascosta .vscode e all’interno un file settings.json per registrare le impostazioni dello spazio di lavoro. Potete semplicemente copiare questo file da un progetto all’altro, se volete mantenere le stesse impostazioni in diversi progetti. Se non trova un settings.json nello spazio di lavoro (o se aprite semplicemente un file, e non una directory) allora Code usa solo le impostazioni generali.
Nell’elenco dei setting, un’attenzione particolare meritano le varie path. La path predefinita per l’interprete Python è "python.pythonPath": "python" che come già sappiamo punta al primo interprete che Windows trova nella path di sistema. Potete lasciare questa impostazione così com’è, oppure selezionare manualmente un venv “generico” in cui preferite installare i pacchetti di uso più comune. Impostate poi "python.venvPath" con la directory in cui risiedono i vostri venv (noi fin qui abbiamo usato "D:/envs). In questo modo Code mantiene un elenco di tutti i venv che avete creato, oltre a quelli che trova installati globalmente. Code vi mostra sempre quale interprete sta usando attualmente, nella barra di stato: se non è quello giusto, basta cliccarci sopra per sceglierne un altro. Una volta che Code lavora nel venv giusto per il vostro progetto, anche l’autocompletion funzionerà meglio, mostrandovi i suggerimenti dai pacchetti che avete installato nel venv.
Potete accedere a una shell Python senza bisogno di uscire da Code: aprite la palette dei comandi (shortcut Ctrl+Shift+P) e inserite “Python: Start REPL” (l’autocompletion vi aiuterà). Eccovi pronta una shell Python interattiva, che usa lo stesso interprete del vostro codice, e “vede” quindi gli stessi pacchetti installati.
Il linter predefinito è PyLint, ma potete configurarne altri (e anche più di uno). Chiaramente PyLint va installato, prima di poterlo usare: se Code non lo trova, si offre di istallarlo per voi. I messaggi di PyLint sono riassunti nella barra di stato: cliccate per avere un report più dettagliato. Code rispetta le impostazioni di PyLint per il filtraggio dei messaggi, se usate un file .pylintrc: vi rimandiamo alla guida per i dettagli.
Se avete installato Git, allora Code vi offre una discreta integrazione: il pulsante “Git” nella barra di sinistra vi consente di fare le operazioni più comuni (commit, push, pull…). La barra di stato mostra la branch attiva e vi permette di fare un checkout. Per altri comandi anche piuttosto comuni (tag, log…) dovete comunque usare la shell, ma tutto sommato potete gestire la maggior parte del vostro flusso di lavoro dall’interno dell’editor. Nei progetti dove non volete usare Git, vi conviene impostare "git.enabled": false nelle preferenze dello spazio di lavoro.
Code e Python for Visual Studio Code vi offrono molte altre opzioni relative a fattorizzazione, formattazione, unit test, debugging, integrazione con Jupyter. La guida spiega tutto nel dettaglio.

Font per programmatori.

Una delle prime cose che in genere si fanno dopo aver installato un editor, è configurare l’aspetto estetico. Non è solo per divertirsi con le impostazioni: dopo tutto, passerete parecchie ore a fissare la finestra del vostro editor, e non può essere una cosa sgradevole da fissare. Per esempio, molti programmatori preferiscono una combinazione di colori scura (come l’onnipresente Monokai o una delle sue varianti) perché la trovano più riposante per gli occhi.
La scelta più importante, tuttavia, è quella di un font con cui visualizzare il codice. Naturalmente non può essere un font a larghezza variabile come quelli usati di solito in tipografia: è necessario usare invece un font a larghezza fissa (stile “macchina da scrivere”) per avere incolonnamenti esatti, vedere la lunghezza delle righe, etc. Tra i font a larghezza fissa, occorre scegliere quelli che permettono di distinguere bene alcuni caratteri simili: “zero” e “o maiuscola”, “uno” e “elle minuscola”, “punto e virgola” e “due punti”, e così via. Per esempio se lo “zero” non è barrato, allora non è un font da programmatore, e così via.
Un altro fattore determinante per la scelta del font è la resa a diverse dimensioni, a seconda della geometria del vostro schermo. Qui occorre tener conto che, per regola, la riga non dovrebbe essere più lunga di 79 caratteri. Mantenendo la finestra dell’editor a tutto schermo, la dimensione “giusta” del font è quella che vi consente di avere tutta la riga visibile, lasciando spazio a destra e a sinistra per gli ulteriori elementi grafici previsti dall’editor (barre laterali, gutter, numeri di riga…). Siccome molti editor hanno elementi laterali ingombranti, un fattore di pregio per un font è la sua “compattezza” (una buona crenatura): la riga deve essere densa, ma restare ugualmente ben leggibile. In ogni caso, se il font non rende bene quando è regolato alla dimensione giusta per il vostro editor e il vostro schermo, è meglio cambiare font piuttosto che adattare il layout dell’editor.
Un aspetto decisamente meno importante è la resa del font con diverse formattazioni. Qui il fatto è che il codice è sempre “puro testo” non formattato: tuttavia molti editor applicano una formattazione automatica a seconda del contesto (per esempio, i commenti sono resi in corsivo, etc.). Ovviamente è possibile personalizzare (ed eventualmente abolire) queste scelte di formattazione, ma conviene comunque scegliere un font che sia leggibile anche in corsivo e in neretto.
Windows è già dotato di uno dei migliori font “da programmatore” in circolazione, ovvero Consolas che è uno dei font selezionabili nella shell cmd.exe. Molti preferiscono comunque la sua variante open source Inconsolata. Altre scelte molto popolari sono Anonymous Pro, Source Code Pro, Ubuntu Mono per chi è abituato a Linux (o qualche clone open source di Menlo o Monaco per chi è abituato al Mac). Ma le scelte sono veramente molte, e nuovi font interessanti nascono ogni giorno. Per iniziare, Consolas/Inconsolata andrà benissimo.

Librerie Python che potrebbero essere utili in Windows.

Per finire, una rapida rassegna di alcune librerie “Windows-oriented” che occasionalmente potrebbero tornare utili. Attenzione però: se usate alcuni di questi pacchetti rinunciate alla compatibilità cross-platform, e vi rivolgete esclusivamente all’ambiente Windows.

• PyWin32 di Mark Hammond, è un wrapper intorno a molte api di Windows, in modo particolare le Win32 Api e COM. È un progetto vecchio e poco aggiornato, ma d’altra parte anche le api della controparte Windows sono molto stabili. La documentazione è scarsa, e si trova soprattutto all’interno del pacchetto sotto forma di un vecchio .chm: tuttavia, la vera documentazione a cui fare riferimento è quella delle api di Windows. Sul sito si possono scaricare delle versioni compilate (build) per varie versioni di Python, ma tutte pacchettizzate come eseguibili .exe. Da qualche tempo sono anche disponibili su PyPI e quindi installabili con Pip.
• Pythonnet integra le CLR di .NET in Python, e viceversa. In pratica vuol dire che potete chiamare le API della CLR da dentro il vostro codice Python, oppure usare librerie Python da dentro il vostro codice C#. Si tratta naturalmente di uno strumento indispensabile se volete usare Python in .NET (l’alternativa è usare IronPython, vedi sotto). Siccome da qualche tempo la CLR di .NET è disponibile anche per Linux, si può ottenere un inaspettato livello di cross-compatibilità.
• PyHook cattura eventi globali del mouse e della tastiera in Windows. È un progetto vecchio ma tutto sommato stabile e ben documentato (vedere la sezione “wiki”). L’installer ufficiale è un eseguibile, ma probabilmente è meglio usare le wheel di Chris Gohlke (anche per Python 3).
• Py2exe permette di pacchettizzare script Python in eseguibili .exe per l’esecuzione su computer dove non è installato Python. Si tratta di un progetto molto vecchio, che non è mai stato convertito per Python 3: è preferibile usare Cx_freeze o PyInstaller, invece (vedi sotto). Se volete provare Py2exe, è meglio usare le wheel fornite da Chris Gohlke (dove si trova anche una versione non ufficiale per Python 3.4, che probabilmente quindi non funzionerà per le versioni 3.5/6/7 che richiedono un compilatore diverso). In generale, l’idea di distribuire software Python per Windows sotto forma di eseguibili .exe è chiaramente attraente, ed è anche una delle prime cose che un principiante desidera fare. Si tratta però di un argomento molto vasto e complesso: i tool come Py2exe funzionano bene nei casi semplici (progetti “pure-Python” senza dipendenze esterne complicate) ma non è affatto raro imbattersi in difficoltà di vario tipo.
• Cx_freeze genera eseguibili .exe da script Python: a differenza di Py2exe, è attivamente sviluppato, ben documentato, installabile con Pip. Vi conviene comunque tenere d’occhio il bug tracker per avere un’idea dei possibili problemi che potreste avere.
• PyInstaller è un’altra opzione da tentare per generare eseguibili .exe da script Python. Sviluppato, documentato, installabile con Pip, disponibile per Python 3. Anche in questo caso, se qualcosa va storto un’occhiata al bug tracker può essere d’aiuto.
• Pynsist è ancora un’altra opzione per creare installer: è un wrapper intorno a NSIS che quindi va installato a parte e “globalmente” (poi Pynsist può essere installato con Pip anche in un venv).
• WxPython è uno dei gui framework storici per Python. Anche se molti preferiscono i framework concorrenti basati sulle Qt (PySide e wxQt), wxPython ha un notevole seguito specialmente su Windows perché permette di realizzare interfacce grafiche con un look nativo sulle diverse piattaforme. Ne esistono due versioni: wxPython “classic” (la serie 3.x) è ormai superata; wxPython “Phoenix” è la nuova versione per Python 3 (ma compatibile anche per Python 2.7), che dopo lunga attesa è uscita dalla versione beta ed è ormai distribuita come wxPython 4.x. Phoenix si può installare normalmente con Pip. La demo, che è fondamentale per orientarsi, si deve scaricare separatamente e scompattare: una volta estratti i file in una directory qualunque, per avviare la demo basta un normale py demo.py dalla shell (ovviamente, dovete aver attivato il venv in cui avete già installato wxPython).

Distribuzioni alternative di Python.

Esistono alcune distribuzioni alternative di Python, curate da terze parti, che installano non solo Python e la sua libreria standard, ma anche una selezione curata di pacchetti e framework esterni. Fino a non molto tempo fa, come abbiamo visto, in Windows era difficile installare molti pacchetti con estensioni non pre-compilate: le distribuzioni alternative erano un modo facile per poter usare questi pacchetti, dal momento che i curatori della distribuzione li fornivano già pre-compilati. Con l’introduzione di Pip e del nuovo formato Wheel, è diventato molto più facile trovare pacchetti pre-compilati per Windows, e ormai non c’è quasi più bisogno di ricorrere a distribuzioni alternative solo come escamotage per usare certi pacchetti. Ha senso invece ricorrere a una distribuzione alternativa se offre un reale vantaggio rispetto al tipo di lavoro che vogliamo fare (per esempio, Anaconda per certi ambiti scientifici, tecnologici, accademici).

• WinPython ha il vantaggio di essere completamente “portable”: non richiede installazioni, ed è interamente compresa in una directory. E’ orientata alla comunità scientifica; offre l’ambiente grafico PyQt, e l’IDE Spyder.
• PythonXY è analoga a WinPython (Qt e Spyder compresi), ma è disponibile solo per Python 2.
• ActivePython è una delle distribuzioni storiche di Python. Più orientata all’ambiente corporate, il suo vero punto di forza è probabilmente la stabilità dei pacchetti selezionati e il customer support.
• Anaconda è forse la distribuzione più famosa, popolarissima in ambito scientifico. È una vera e propria piattaforma multi-linguaggio (oltre a Python, anche R) basata sul packet manager Conda. Installa automaticamente oltre 150 pacchetti, e altre centinaia sono installabili successivamente con Conda.
• Canopy è il competitor di Anaconda, molto simile come target (comunità scientifica) e strumenti (packet manager proprietario, editor grafico, centinaia di pacchetti supportati…). Le differenze sono apprezzabili praticamente solo nei termini dei diversi ambiti applicativi: alcune comunità lavorano su Canopy, altre su Anaconda.

Implementazioni alternative di Python.

L’implementazione ufficiale di Python, l’unica sviluppata e supportata dalla Python Software Foundation, è CPython, scritta in C, che è quella che abbiamo preso fin qui in considerazione. Ma esistono altre implementazioni curate da terze parti: le più note sono Jython il cui bytecode viene eseguito dalla Java Virtual Machine, e PyPy, un’implementazione di Python scritta in CPython che offre un JIT compiler e stackless mode per aumentarne velocità e capacità in concurrency.
Un’implementazione dedicata al mondo Windows è IronPython, scritta in C# e integrata in .Net: uno script IronPython può usare le librerie .Net allo stesso modo delle consuete librerie Python. Purtroppo IronPython implementa solo Python 2, ma di recente lo sviluppo è ripreso e ci sono piani per implementare anche Python 3.