[Python] Python 2.7 & 3 - afraid and terrified (?)

[Alberto De Prezzo]

Il giorno 13 luglio 2014 23:10, Dario Bertini <berdario a gmail.com> ha
scritto:

> il problema più grosso è lo split fra bytes e unicode
>
>
Lungi da me fare il difensore del BDFL, ma la smoother transition che state
ipotizzando ed argomentando, *credo* che alla fine della fiera non possa
essere fatta meglio di come sta avvenendo.
Quello che intendo io è che ci sono troppi punti di rottura con l'avvento
della 3, e non si tratta -solo- di sintassi e sottigliezze.
Sappiamo tutti che Python è molto cambiato, e sottovoce dico che è stato
molto migliorato e che per molti aspetti, se non avesse armonizzato tutti
questi aspetti, non so che futuro avrebbe avuto. IMHO, creare una versione
che faccia da ponte, andrebbe a creare molti piu' svantaggi che altro,
perchè in tale Python 2.8 dovrebbe convivere tutto (ed il contrario di
tutto).
Per gli aspetti per cui è possibile scrivere codice *python3 ready*, è già
a disposizione il builtin __future__, per la gestione di features e
keywords mandatory.  E' vero, per alcuni aspetti ci sarebbero pochi
problemi. Ad esempio, con il *raise* degli errori, che con  Py2 poteva
avvenire in 2 modi:
>>>raise TypeError, "errore xxx"
>>>raise TypeError("errore xxx")
e con py3 solo con la seconda forma: no-problem, si permettono ambedue le
sintassi ed il problema è risolto.
Così come le eccezioni ora non possono piu' essere lanciate con
>>>except ValueError, my_err
ma
>>>except ValueError(my_err)
anche qui non sarebbe un problema permettere ambedue le sintassi.
Anche print vs. print() è  una modifica sintattica, gestibile in una
ipotetica 2.8.
Anche se c'è da notare che in python 2 il seguente codice è sintatticamente
valido, ma restituisce una tupla.
>>>print('foo','bar').
Ma non è sempre così agevole il discorso. Ci sono cose nella 2.7 che non
sono accettabili:
La gestione degli operatori di divisione degli interi in python 2 è
abbastanza incomprensibile.
Unicode: Molto più pulito avere finalmente utf-8 *nativo*, ed a
disposizione byte (e bytearray). Basta con questi str() e unicode() da
wrappare assieme.
Sulle iterazioni, range soppianta e migliora xrange. E il __contains__, non
presente nella 2, rende impossibile l'utilizzo del costrutto "x in in
[x]range(foo)".
Alcuni comportamenti non-lineari nella gestione del namespace sono stati
eliminati. Il namespace globale è sempre isolato dai loop for e
comphrension varie. Niente piu' anomalie nel global namespace dopo le
iterazioni. wow.
Senza entrare troppo nello specifico di iteratori/iterabili/ __next__ e
__iter__, anche qui dico una sola cosa: ci basta solo il next(), niente più
metodo  obj.next(). E niente piu' scelta fra input() e raw_input(). C'è
solo input() che gestisce <str>. amen.
Niente piu' stranezze sulla comparazione di tipi differenti
>>('foo','bar') > 'baz'
True # WTF???
IMHO è stata razionalizzata e potenziata anche la gestione degli iterabili.
Spesso non si ha un ret val <list> ma <iterable> (zip(), map(),
dict.keys(),...). Ora c'è semplicemente la possibilità di conversione in
list() a seconda delle necessità di iterazione, a seconda se c'è esigenza
di prestazioni/efficienza o persistenza (1-time-loop vs. n-time-loop).

E via discorrendo. Questi sono i primi punti che mi sono venuti in mente,
sono convinto che ce ne sono molti altri. Anche se mi sto accorgendo di
andare abbastanza controcorrente rispetto al pensiero diffuso in questa ML,
ripeto: IMHO è difficile fare transizioni morbide, quando si deve cambiare
e migliorare così tante cose. In una ipotetica 2.8 immagino codice zeppo di
"if python_version()" o "try/except" per gestire un marasma del genere,
ergo nello Zen andrebbero quindi cancellati:
Beautiful is better than ugly.
Readability counts.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Now is better than never.
Although never is often better than *right* now.



my two cents.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20140714/639cc337/attachment.html>