Re: [Python] Python 2.7 & 3 - afraid and terrified (?)
Il giorno 13 luglio 2014 23:10, Dario Bertini 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 . 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 ma (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.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Python 2.7 & 3 - afraid and terrified (?)
2014-07-13 18:32 GMT+02:00 Dario Bertini : > > Vero, dimenticavo questo particolare (che è una delle argomentazioni > convincenti per un Python2.8, se ben ricordo) > A conti fatti credo sia l'unica, ma ovviamente non basta. > A > > parer mio la situazione è preoccupante non tanto per il numero esiguo di > > migrazioni fatte finora, quanto per il fatto che non vedo segnali di > > miglioramento per l'immediato futuro. Le migliorie sintattiche/puristiche > > interessano poco e la migliore gestione di unicode per molti è > addirittura > > un problema anzichè un vantaggio. Di fatto credo che ad oggi l'unico vero > > incipit a migrare sia il fatto che la 2.7 diventerà obsoleta quindi si > sarà > > semplicemente obbligati a migrare (e neanche tutti) ma quando l'incipit > è un > > bastone anzichè una carota non è mai un bene. > > > > "incipit" mi ha un po' confuso, l'autocorrettore ti ha sostituito > "incentivo"? :P > Argh! Si! (e non è stato l'autocorrettore, vergogna) :D > ancora: sono d'accordo, ma come dicevo all'inizio... imho è più un > problema "sociale" o "di persone" che un problema tecnologico. La > carota c'è, solo che non ha la stessa dimensione per tutte le > aziende/tutti i progetti esattamente come il problema di migrare > una codebase come quella di OpenStack non è un problema comune a molti > altri. Dipendenze quali Twisted, gevent e MySQL-python sono purtroppo comuni a molti. Troppi. -- Giampaolo - http://grodola.blogspot.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python 2.7 & 3 - afraid and terrified (?)
2014-07-13 23:10 GMT+02:00 Dario Bertini : > 2014-07-13 11:05 GMT-07:00 Giovanni Porcari >: > > > > Domanda da ignorante: Ma è radicalmente impossibile pensare ad una > versione > > di python 3 che sia in qualche modo completamente retrocompatibile con > la 2.7 > > o con una ipotetica 2.8 ? > > il problema più grosso è lo split fra bytes e unicode > A conti fatti direi che è l'unico, il solo aspetto che rende Python 3 profondamente diverso dal 2. Tutto il resto è facilmente portabile con 2to3 e six con relativamente poco sforzo, specialmente se il target è Python 2.6+. La distinzione netta tra bytes e "testo" è stata una scelta molto (troppo?) coraggiosa e moderna, "giusta" in linea di principio ma fortemente non retrocompatibile e a cui si deve l'attuale spaccatura. Non è un caso che proprio i progetti fortemente basati sull'I/O come MySQL-python, Twisted e gevent sono quelli che ancora latitano perchè (esperienza personale fatta con pyftpdlib) far coesistere due tipi che prima erano intercambiabili e di colpo non lo sono più, specialmente in quel tipo di applicazioni, è veramente un casino. Hai bytes che ti viaggiano "sul cavo" come bytes in entrata e in uscita ma che a livello di codice devi trattare com testo, per cui ti devi porre 2 problemi che prima non ti ponevi: sapere in anticipo in che encoding trattarli e cosa fare se quello che ti entra non è convertibile "non per colpa tua". Problemi che in linea di principio è giustissimo porsi se si vivesse in un mondo perfetto dove client, file system e sistemi operativi usassero tutti correttamente UTF-8, ma che non corrisponde a quello reale in cui molte volte non sai l'encoding e vuoi semplicemente che una cosa *funzioni* il 99% delle volte e rispondere "cazzi tuoi" a quell'1% di utenza che usa un client fatto male. E guarda caso questo è esattamente il trend adottato dalla maggior parte delle aziende, che sono quelle che determinano il successo di un prodotto. Se non ci fosse stata la modifica a bytes/unicode *oggi* saremmo già tutti su python 3, ne sono assolutamente convinto, sia perchè il 2 è destinato a morire e sia perchè il 3 è dannatamente buono (nuova gestione delle eccezioni, traceback concatenati, tuple unpacking, mandatory kwargs, __pycache__, TypeError ogni volta che mischi/compari mele e pere, pathlib, asyncio, enum... tutta roba buona). 3 / 2 = 1.5, "except Exception as ex:", list(range), metaclass=..., etc. sono problemi solo un po' più difficili di quelli che si affrenterebbero in transazioni come dalla 2.4 alla 2.5 per dire, e che risolvi egregiamente con six. Un Python 2.8 non risolverebbe assolutamente nulla se non prolungare ulteriormente l'attesa, perchè apparentemente non è possibile trovare un punto di incontro tra come Python 2 e 3 gestiscono "testo" e bytes. O li si gestisce in un modo o in un altro, ed il problema stà unicamente lì. -- Giampaolo - http://grodola.blogspot.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python 2.7 & 3 - afraid and terrified (?)
2014-07-14 16:09 GMT+02:00 Giampaolo Rodola' : > > > > 2014-07-13 23:10 GMT+02:00 Dario Bertini : > > >> > [...] > Non è un caso che proprio i progetti fortemente basati sull'I/O come > MySQL-python, Twisted e gevent sono quelli che ancora latitano perchè > (esperienza personale fatta con pyftpdlib) far coesistere due tipi che > prima erano intercambiabili e di colpo non lo sono più, specialmente in > quel tipo di applicazioni, è veramente un casino. > Hey, aspetta un attimo. str e unicode non sono **mai** stati intercambiabili, a meno di applicazioni affette da gravi bug logici e che dipendevano dall'encoding di default. > [...] Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python 2.7 & 3 - afraid and terrified (?)
2014-07-14 16:32 GMT+02:00 Manlio Perillo : > > 2014-07-14 16:09 GMT+02:00 Giampaolo Rodola' : > > >> >> >> 2014-07-13 23:10 GMT+02:00 Dario Bertini : >> >> >>> > [...] > >> Non è un caso che proprio i progetti fortemente basati sull'I/O come >> MySQL-python, Twisted e gevent sono quelli che ancora latitano perchè >> (esperienza personale fatta con pyftpdlib) far coesistere due tipi che >> prima erano intercambiabili e di colpo non lo sono più, specialmente in >> quel tipo di applicazioni, è veramente un casino. >> > > Hey, aspetta un attimo. > str e unicode non sono **mai** stati intercambiabili, a meno di > applicazioni affette da gravi bug logici e che dipendevano dall'encoding di > default. > > > [...] > Mi riferisco a: >>> u"a" + "b" u'ab' >>> "a" == u"a" True -- Giampaolo - http://grodola.blogspot.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python 2.7 & 3 - afraid and terrified (?)
2014-07-14 16:43 GMT+02:00 Giampaolo Rodola' : > [...] > > [...] >> >>> Non è un caso che proprio i progetti fortemente basati sull'I/O come >>> MySQL-python, Twisted e gevent sono quelli che ancora latitano perchè >>> (esperienza personale fatta con pyftpdlib) far coesistere due tipi che >>> prima erano intercambiabili e di colpo non lo sono più, specialmente in >>> quel tipo di applicazioni, è veramente un casino. >>> >> >> Hey, aspetta un attimo. >> str e unicode non sono **mai** stati intercambiabili, a meno di >> applicazioni affette da gravi bug logici e che dipendevano dall'encoding di >> default. >> >> > [...] >> > > Mi riferisco a: > > >>> u"a" + "b" > u'ab' > >>> "a" == u"a" > True > > > In [1]: u"à" == "à" /usr/bin/ipython2:1: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal #!/usr/bin/python2 Out[1]: False Ciao Manlio ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python 2.7 & 3 - afraid and terrified (?)
2014-07-14 17:06 GMT+02:00 Manlio Perillo : > 2014-07-14 16:43 GMT+02:00 Giampaolo Rodola' : > > > [...] > >>> [...] >>> Non è un caso che proprio i progetti fortemente basati sull'I/O come MySQL-python, Twisted e gevent sono quelli che ancora latitano perchè (esperienza personale fatta con pyftpdlib) far coesistere due tipi che prima erano intercambiabili e di colpo non lo sono più, specialmente in quel tipo di applicazioni, è veramente un casino. >>> >>> Hey, aspetta un attimo. >>> str e unicode non sono **mai** stati intercambiabili, a meno di >>> applicazioni affette da gravi bug logici e che dipendevano dall'encoding di >>> default. >>> >>> > [...] >>> >> >> Mi riferisco a: >> >> >>> u"a" + "b" >> u'ab' >> >>> "a" == u"a" >> True >> >> >> > In [1]: u"à" == "à" > /usr/bin/ipython2:1: UnicodeWarning: Unicode equal comparison failed to > convert both arguments to Unicode - interpreting them as being unequal > #!/usr/bin/python2 > Out[1]: False > Ecco, classico esempio di codice che funziona "il più delle volte" ma nasconde un baco e che Python 3 ha risolto lanciando TypeError. E' esattamente a questo che mi riferivo: sono intercambiabili nel senso che li puoi mischiare (e come in questo caso ottenere risultati errati) e anche formattarli entrambi (cosa che non puoi fare coi bytes in python 3 e che è quello che crea maggiormente problemi alla gente di twisted e mercurial). -- Giampaolo - http://grodola.blogspot.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Python 2.7 & 3 - afraid and terrified (?)
On 07/08/2014 09:16 PM, Alberto De Prezzo wrote: La mia curiosità è la seguente: quotidianamente, i partecipanti a questa ML, con che versione si trovano a lavorare maggiormente? Sia la 2.x che la 3.x . Questo perche` la distribuzione che uso lato server (CentOS 6.x) ha solo la 2.x, mentre io sviluppo con la 3.x (compilata a mano, per mia sfortuna) Quanti, oggi, dovendo iniziare un progetto, utilizzano ancora la 2? Solo se sono costretto :) In ogni caso, secondo me uno dei problemi che hanno limitato fino ad ora la diffusione di 3.x e` che le distribuzioni enterprise ancora non si decidono a supportarlo seriamente. Se Debian ha rilasciato due release con Python 3.x, cosi` non si puo` dire per SuSE e RHEL, che ancora non lo hanno tra i suoi pacchetti o lo hanno in modo controverso (RHEL 7 lo rilascia tramite RHSCL). Questo va ad aggiungersi al mancato rilascio di pacchetti compilati da parte del sito ufficiale, che rende l'installazione solamente previa compilazione dell'interprete, osteggiata da molti sysadmin Enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] Chi si intende di comunicazione fra processi?
Salve a tutti, Oggi stavo cercando di far partire un sottoprocesso dallinterno di uno script python. Sono sotto windows e utilizzo il modulo subprocess. Come processo sto utilizzando lo stesso python.exe, prima di scrivere il mio programma che deve far partire un altro programma aziendale. Ora non so se è il mio screen reader che mi si blocca ma, quando tento di leggere dallo standard output, con ReadLine, si pianta tutto. Ho provato a fare la stessa cosa in c#, sempre prendendo python.exe come sottoprocesso e mi sono accorto che questi non scrive sullo standard output. Dunque sono ritornato al mio script python e, con la funzione communicate di subprocess riesco a far terminare python.exe il quale mi riscrive sullo stdout tutto quello che gli ho mandato ma poi termina Ora, forse la mia mente si è obnubilata, ma non ci sto capendo piu niente Qualcuno mi sa dare lumi? Grazie! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
