UTF-8: accenti o non accenti?

[Risca]

Riprendo qui il discorso aperto con questi due thread (1[/url=http://forum.debianizzati.org/viewtopic.php?f=60&t=42739#p126630] e [url]2): tutta questa bufera sugli accenti mi ha spinto a cercare la soluzione definitiva.
Per prima cosa bravo GipPasso:

Perché non ci vogliono gli accenti negli script in python che sono scritti in utf-8? Anche i peggiori sistemi operativi su cui si può installare python3 supportano utf-8.
Siamo nel 2011 e ancora abbiamo problemi con i caratteri accentati?

La situazione è un po' più complessa, ma vediamo un po' nel dettaglio.
Leggendo lo standard (http://www.python.org/dev/peps/pep-0008/) risulta chiaramente che in python3 si debba usare la codifica utf-8, che quindi comprende gli accenti:

For Python 3.0 and beyond, UTF-8 is preferred

Però, penso per ragioni storiche nonché di internazionalizzazione, il codice (regola di stile) dovrebbe rimanere pulito da detti orpelli:

All identifiers in the Python standard library MUST use ASCII-only identifiers, and SHOULD use English words wherever feasible (in many cases, abbreviations and technical terms are used which aren't English). In addition, string literals and comments must also be in ASCII.

Il motivo mi pare molto chiaro, i computer parlano Inglese (se non sbaglio Inglese-americano)!
Ovviamente c'è una eccezione:

The only
exceptions are (a) test cases testing the non-ASCII features, and
(b) names of authors. Authors whose names are not based on the
latin alphabet MUST provide a latin transliteration of their
names.

Premesso questo, secondo me, dal momento che gli script che scriviamo sono localizzati in Italiano, potrebbe essere corretto utilizzare gli accenti negli oggetti di testo (i dialoghi con l'utente) fatta salva la regola che tutto il resto debba essere senza accetti ed in Inglese.

Per chi ha voglia di approfondire avevo già aperto una pagina di appunti da dedicare allo stile in Python: http://guide.debianizzati.org/index.php ... i_lo_Stile
Oltre a completarla forse se ne potrebbe discutere nel corso del prossimo incontro.

[Stemby]

Ho visto solo ora la discussione. Ho risposto qui.

Ciao!

[GipPasso]

Come sappiamo in inglese non si usano caratteri al di fuori della tabella ASCII, e quindi ogni problema è risolto alla radice.

Secondo me qui si confondono il concetto di "risoluzione" e di "aggiramento" del problema.
Scrivendo file utf-8 il problema è risolto.
Scrivendo in inglese è aggirato.

Io scrivo in inglese non cerco per virtù particolari ma da più di un decennio è la mia "working language" unica e insostituibile. Non per questo tengo tantissimo a scrivere i miei script privati in italiano e possibilmente nel migliore e più corretto.

Il concetto di "portabilità" ha senso solo in certi contesti. Quando lavoro è pretesa (non ultimo da me stesso). Se mi scrivo lo scriptino che mi automatizza le mie cosette (vivo di ratpoison, screen ed emacs, non conoscendo ancora elisp e preferendogli per ora python un po' di automatismi per ridurre le scorciatoie di sistema inutilmente ripetitive serve!) pretendo che la questione lingua sia risolta, nel senso accennato prima.

In sintesi: il python "privato" lo scriverò in italiano, con accenti, metafonesi e cedilles varie (mannaggia agli amici svizzeri, francesi e tedeschi!).
Per un fatto di puro evitarsi mal di fegato non userò questi caratteri che nei commenti e nelle stringhe testuali, ma solo perché una buona vecchia abitudine non deve esser abbandonata.

Di inglese al lavoro ne mastico anche troppo (e questo mi acquisce solo il senso di mancanza dell'inglese letterario, roccaforte contro il forzato depauperamento lessicale operato dal gergo tecnico) e dato che il python soddisfa (per quanto io abbia finora colto) anche i più fini esteti della programmazione, lo userò come ulteriore mezzo di godimento della nostra splendida lingua.

Chi invece sente di voler far esercizio linguistico, non solo fa bene ma deve scrivere tutto in inglese, soprattutto commentando molti passaggi e profondendosi in spiegazioni delle scelte operate, esercitando così la lingua e la consapevolezza del programma scritto.

GipPasso

[Stemby]

Come sappiamo in inglese non si usano caratteri al di fuori della tabella ASCII, e quindi ogni problema è risolto alla radice.

Secondo me qui si confondono il concetto di "risoluzione" e di "aggiramento" del problema.
Scrivendo file utf-8 il problema è risolto.
Scrivendo in inglese è aggirato.

No, non è aggirato: proprio non si pone. Comunque questi sono sofismi; la sostanza del discorso credo che sia chiara.

Per la cronaca, con Debian il problema non si dovrebbe mai verificare, in quanto tutti gli editor (per quanto ne so io) usano di default la codifica UTF-8, che con Python3 è la codifica nativa e compresa dall'interprete senza ulteriori sforzi aggiuntivi.

Per gli script privati è ovvio che ognuno si regola come preferisce. Io mi son dato la regola di scrivere in inglese: non si può mai essere sicuri che un pezzo di codice non tornerà utile in futuro in un progetto pubblico.

[EDIT]
Posso capire al limite stringhe e commenti nella lingua locale, ma l'idea di avere nomi di variabili, funzioni, classi, ecc. in italiano mi fa rabbrividire. Cose tipo

Codice: Seleziona tutto

età = input("Età: ")

davvero non riesco a sopportarle...

(un po' come spazi, lettere accentate e porcherie varie nei nomi dei file)

[GipPasso]

A mio avviso è una questione di base. Risolvere il problema degli accenti scrivendo senza accenti vuol dire sgusciare dal problema, accettare una limitazione per non incorrere nel problema stesso. In sintesi, aggirarlo.

Se python avesse questo problema l'avrei già abbandonato, anzi, neppure iniziato.

L'ho scelto proprio perché nativamente utf-8, cioè con problema risolto. Io sono italiano che ha studiato e viaggiato parecchio in Europa (per mia fortuna, non meriti). Avere un mezzo che non supporta nativamente i caratteri delle lingue che qui si parlano lo ritengo una cosa ridicola.
Per me utf-8 è il minimo, consentendomi immediatamente di scrivere qualsiasi lingua abbia mai studiato (per esempio francese o greco sulle altre). Inoltre non mi dispiacerebbe avere l'occasione, professinale, di dover mettere mano al cinese e cambiare ogni volta codifica sarebbe come cambiare penna al cambiamento della lingua scritta: non se ne vede il motivo.

Questo è un aspetto base che colloca python tra i linguaggi ad alto livello (con relativi pregi e difetti) assolutamente moderni (e questo ne è solo forse un esempio piccolissimo). Però è una marca assolutamente caratteristica del come è stato concepito.

Python 3 è, d'altronde, l'implementazione del linguaggio sviluppato dal progetto Python 3000 (questo quanto ho capito), e avere dei vincoli strutturali all'ASCII sarebbe veramente poco degno di quel numero (che voleva essere una presa in giro del 2000 in voga in quel periodo).

Se poi qualcosa deve circolare in mano a chi non si sa, è chiaro che vada scritta in inglese. Questa è storia dell'oggi però, non qualità intrinseca alla lingua e, per fortuna (ma come dicevo prima è anche conditio sine qua non), vincolo dello strumento sotto studio.

GipPasso

[GipPasso]

Posso capire al limite stringhe e commenti nella lingua locale, ma l'idea di avere nomi di variabili, funzioni, classi, ecc. in italiano mi fa rabbrividire.

In parte anche a me. Sono troppo inveterati gli anglismi in qualsiasi cosa di tecnico che faccia.

La questione è però semplice: che rilevanza ha la nostra opinione?

Stiamo studiando uno strumento. Rendiamo giustizia alla sua versatilità e non poniamo questa dei limiti che essa non ha.

Le convenzioni "migliorative" in tal senso sono chiaramente documentate (grazie per la dovizia e autorevolezza delle fonti citate anche a tal proposito) e la nostra preferenza a esse accordate è altrettanto chiara e per le stesse ragioni ivi citate.

Perché però la convenzione svolga appieno il suo ruolo, indichiamola chiaramente e indichiamo altrettanto limpidamente quanto questa non si basi sul python 3.
Non c'è libro di fisica teorica che si rispetti che non indichi a chiarissime lettere che pone h=c=1.
Nessuno si chiede più il perché, e non so chi usi sistemi diversi in questo settore. Eppure è, a tutt'oggi, espressamente indicata tutte le votle. Questa è, per me, una buona convenzione: quella indicata con chiarezza tale da far capire al volo la sua natura convenzionale e non fondamentale.

GipPasso

[Stemby]

A mio avviso è una questione di base. Risolvere il problema degli accenti scrivendo senza accenti vuol dire sgusciare dal problema, accettare una limitazione per non incorrere nel problema stesso. In sintesi, aggirarlo.

Ma non è così! Si scrive in inglese non perché in inglese non ci sono gli accenti, ma perché è la lingua franca dell'informatica. Semmai è il contrario: è la tabella ASCII che non ha le lettere accentate perché non servono, scrivendo in inglese[1]. La cosa può piacere o meno (io non amo l'inglese, tra parentesi), ma la realtà attuale è questa. Magari tra 50 anni scriveremo tutti in cinese, chi lo sa.

Oggigiorno, però, non usare l'inglese nel software libero è un errore strategico, indipendentemente dal linguaggio di programmazione adottato. Ricordo di un gruppo di brasiliani che hanno preso una libreria (mi sfugge quale, era in ambito CAD) e l'hanno sviluppata. L'hanno però dovuta riscrivere praticamente da zero, perché era... in esperanto! Teoricamente l'esperanto potrebbe anche essere la lingua ideale[2] per sviluppare software libero. Ma è davvero dura attrarre sviluppatori utilizzando tale lingua... (ovviamente l'hanno tradotta in inglese, mica in portoghese).

La localizzazione è una fase successiva alla programmazione, e i termini non-inglesi non rientrano mai nei sorgenti. Ovviamente questo passo va compiuto osservando scrupolosamente tutte le regole della lingua; quindi in italiano non si scrive né "perche`" né "perchè", bensì "perché". Tuttavia questo non è un problema che riguarda il programmatore, ma il traduttore.

Con questo non voglio dire che il fatto che py3 supporti nativamente utf-8 sia inutile. In certe circostanze torna comodo. Penso ad esempio a caratteri tipo "µ", o al caso in cui l'autore si chiami Giosuè e voglia inserire il suo nome correttamente nell'indicazione del copyright.

Insomma, prendiamola come una convenzione analoga alle regole "di buona educazione", o alla netiquette. Credo che Debian non si lamenti se salvo un file come "Riunione del 13 febbraio 2011 sul perché non si devono usare gli accenti.pdf", ma non dirmi che non mi prenderesti per un utonto.

[1] e l'acronimo spiega il motivo per cui si è scelta questa lingua...
[2] a mio avviso non lo è, ci sono lingue ausiliarie molto più moderne, semplici ed interessanti

[EDIT]

È vero che la si può ripristinare con

Codice: Seleziona tutto

# -*- coding: utf-8 -*-

Ci ho riflettuto un po' su, e ho concluso che in py3 questa riga è sempre inutile. Se mi sbaglio, ditemelo

Mi spiego: se la codifica del sorgente è UTF-8 (dipende dalle impostazioni dell'editor), quella riga non serve, in quanto py3 di default usa proprio quella codifica; se invece la codifica è diversa (esempio: si è usato un editor sotto windows), allora bisogna indicare la codifica corretta, che chiaramente non sarà utf-8. Immagino che in ogni caso questa seconda ipotesi sia deprecata, e che si consigli fortemente di adottare sempre e soltanto utf-8 come codifica dei caratteri.

[GipPasso]

Questo genere di discussioni rompono presto gli altri, non me. Quindi cerco di tagliarla corta, ma soprattutto ti ringrazio dei contributi. Mi sono molto utili per pensare a questa categoria di problematiche che mi hanno sempre interessato.

Per rispodere al quesito tecnico: sì, ritengo che quella stringa sia inutile se si usa utf-8.

Rispondendo al tuo esempio di nome "fail" ( :P ): sì, ti prenderei per un utonto perché non si danno quei nomi ai file. Su questo siamo entrambi "viziati bene".

E dici benissimo dell'importanza dell'inglese nel software libero (e temo anche sul futuro, magari entro il secolo del ruolo della lingua cinese, chissà). È il fatto che sia "libero", quindi intrinsecamente progettato per girare il mondo che lo vincola all'inglese.

Python è però molto utile anche in contesti più umili, domestici.
In questi casi vien naturale commentarsi lo scriptino per registrare sul tuo nas la radio via web in italiano, dato che la tua rete domestica è facilmente diversa da praticamente tutte le altre e perché lo scriptino lo pensi mentre lo scrivi e poi lo laci lì chissà per quanto.
In questo parlo di problema risolto: il python integra naturalmente tutte le lingue. Se lo usi privatamente è comodo e piacevole non dover affrontare alcuna localizzazione, ma scrivere codice e commenti per come le pensi.

Per i nostri esercizi dell'accademia, non ci son dubbi della lingua da utilizzare. Perché facciamo le cose guardando allo scenario grande, degno del termine "accademia" che ci siamo scelti.

In conclusione: mi godo la libertà di scrivermi le mie cavolatine come mi vengono (mezzo inglesi e mezzo italiane), ma al primo cenno di serietà o condivibilità del codice scritto esiste solo l'inglese.
Il rigore linguistico di Stemby a riguardo è da me interamente sottoscritto.

@ Stemby:
Grazie ancora di spunti e riflessioni.

GipPasso

[Risca]

Purtroppo in questi giorni non ho avuto la possibilità di intervenire, ma leggervi è stato un piacere. Penso abbiate esposto in maniera chiara il problema ed affrontato ottimamente l'argomento.

[Cicciolinuks]

Secondo me la questione è stata espressa chiaramente, manca una cosa:
se in alcuni sistemi è possibile scrivere in python con gli accenti, questo deve essere valido per tutti gli altri sistemi, per motivi di portabilità.
Se poi chi ha il "vizio" di usare la propria lingua e vuole scrivere città invece di citta, non gli deve essere impedito, specie se lo fa a casa. Se poi il programmino che si è fatto per sé diventerà la base portante di un sistema internazionale, allora farà lui copia-sostituisci oppure gli si può dire: "l'hai voluta la bicicletta? Ora pedala".

È una questione di decidere per gli altri e limitare la libertà... se ci sono delle linee guida è dovere del programmatore seguirle, ma a casa sua può fare quel che vuole. Tra l'altro le parole chiave sono in inglese ed immutabili, per il resto il linguaggio non dovrebbe essere troppo invadente, se io non so come si dice città in inglese e posso fare un corso scrivo città e non casca il mondo.
Infine nessuno nasce "imparato", se un ragazzo di 10 anni vuole imparare a programmare non capisco perché fargli prima il corso di lingua. Senza contare che impedire gli accenti non significa impedire l'uso di una lingua: posso ancora chiamare una classe "Persona" e gli attributi "nome", "indirizzo"... ma non "città". Quindi è sempre una cosa a metà.