2014-07-13 23:10 GMT+02:00 Dario Bertini <berda...@gmail.com>: > 2014-07-13 11:05 GMT-07:00 Giovanni Porcari <giovanni.porc...@softwell.it > >: > > > > 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