Uscito Python 3.0

[The_ouroboros]

E finalmente uscito ma........quanto conviene usarlo da subito??

Ciauz

[cdimauro]

Al momento io non posso perché ho codice di produzione che è basato sul 2.5 (quindi nemmeno sul 2.6).

Per quanto mi riguarda i problemi sono due: la mancanza di moduli aggiornati (es: mod_python non c'è nemmeno per la versione 2.6) e il dover effettuare il porting delle applicazioni già scritte.

Personalmente prevedo almeno un anno (se non di più) per pensare di adottarlo stabilmente.

[The_ouroboros]

come pensavo.
Grazie per le tue considerazioni.
Ah, una domanda, come mai non 2.6?

[cdimauro]

Per lo stesso motivo. Di molte librerie sono già uscite le versioni per la 2.6, ma di alcune (come mod_python, appunto, o anche KinterbasDB per FireBird e PyGreSQL per PostgreSQL) ancora non se ne parla.

Anzi, peggio ancora: nemmeno Ice ha ancora il supporto per Python 2.6.

[PhysX]

nella versione 2.6 avevo trovato interessante il modulo multiprocessing e la clausola with, mentre della 3.0 ho letto il changelog ma non ho visto niente di rilevante imho, a parte la gestione dell'unicode (devo ancora provarlo bene pero).

credo che la novita piu importante di questa versione sia l'aver rotto la retrocompatibilità con le vecchie versioni e aver ripulito l'api.

[shinya]

beh, niente di rilevante mi sembra esagerato... di carne al fuoco mi pare ce ne sia parecchia!

http://docs.python.org/dev/3.0/whats...seVersion=true

Anche se questo fa storcere un pò il naso:
"The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5"

[cdimauro]

Originariamente inviato da PhysX

nella versione 2.6 avevo trovato interessante il modulo multiprocessing e la clausola with, mentre della 3.0 ho letto il changelog ma non ho visto niente di rilevante imho, a parte la gestione dell'unicode (devo ancora provarlo bene pero).

Al contrario: la 3.0 si porta dietro tante di quelle modifiche e cose utili, che è da più di anno che sbavo alla sola idea di poterci mettere le mani sopra.

Poi l'istruzione with esisteva già dalla 2.5 (io la uso estensivamente da tempo).

credo che la novita piu importante di questa versione sia l'aver rotto la retrocompatibilità con le vecchie versioni e aver ripulito l'api.

Non è che la retrocompatibilità sia stata persa appositamente. E' che il linguaggio ha subito una "ripulitura" non da poco, e idem le librerie, per cui era inevitabile.

Originariamente inviato da shinya

beh, niente di rilevante mi sembra esagerato... di carne al fuoco mi pare ce ne sia parecchia!

http://docs.python.org/dev/3.0/whats...seVersion=true

Esatto. Ci sono tantissime e succosissime novità.

Anche se questo fa storcere un pò il naso:
"The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5"

Se consideri che fino a qualche beta fa era più lento del 33% circa, hanno fatto un eccellente lavoro.

Purtroppo una perdita di velocità era scontata, visto che adesso non ci sono più interi e interi lunghi, ma esistono soltanto questi ultimi, e inoltre le stringhe sono diventate unicode.

E' un prezzo da pagare, ma lo ritengo giusto per tutto il lavoro di pulizia che è stato fatto.

Comunque sia il compilatore che la virtual machine hanno ampii margini di miglioramento.

[PhysX]

si in effetti guardando meglio avete ragione. non avevo visto le annotations, potrebbero rivelarsi molto utili per gli IDE per fornire autocompletamento, tool tips e type checking durante la digitazione che adesso mancano.

[cdimauro]

Dictionary comprehensions: {k: v for k, v in stuff} means the same thing as dict(stuff) but is more flexible. (This is PEP 0274 vindicated. :-)

Set literals, e.g. {1, 2}. Note that {} is an empty dictionary; use set() for an empty set. Set comprehensions are also supported; e.g., {x for x in stuff} means the same thing as set(stuff) but is more flexible.

[The_ouroboros]

Originariamente inviato da cdimauro

Purtroppo una perdita di velocità era scontata, visto che adesso non ci sono più interi e interi lunghi, ma esistono soltanto questi ultimi, e inoltre le stringhe sono diventate unicode.

non mi sembra tanto male la cosa in effetti

[cdimauro]

Non lo è infatti: c'è un solo tipo intero, e c'è anche un solo tipo stringa (solo Unicode). Per chi vuol manipolare sequenze di byte c'è il tipo byte (che a sola lettura) e bytearray che è mutabile.

Niente duplicazioni e ogni oggetto ha le sue ben precise responsabilità. Mi piace molto. Anzi... non vedo l'ora di poterci mettere le mani sopra.

[~FullSyst3m~]

Hanno sconvolto pure il print. Quale è l'utilità?
Io avrò problemi a passare a questa versione, visto che già il libro che sto studiando si riferisce alla versione 1 e io uso la 2.5 e già parecchie cose sono cambiate

[cdimauro]

Il fatto di avere print come funzione built-in permette di poterla eventualmente rimpiazzare.

Immagina di stare sviluppando un'applicazione e che ti serva visualizzare delle informazioni utili per il debugging. Usi la print normalmente e, quindi, vedi a video tutto ciò che ti serve. Poi devi andare in produzione, ma il codice con le print è rimasto ed è piuttosto fastidioso. Che fare? Semplice: si definisce una funzione che non fa nulla e la si rimpiazza al posto della print:

def NullPrint(*Args, **Keys): pass

install(print = NullPrint)

// Questa è una mia funzione built-in che permette di "installare" facilmente oggetti nel namespace dei bultin-in.
// In questo caso  rimpiazzerebbe la print con NullPrint che... non fa nulla

Questo tipo di situzioni è abbastanza comune, e in questo modo risolvo in maniera molto semplice.

Altra cosa: io generalmente preferisco loggare in un file quelle informazioni, per cui al posto di non farle fare nulla, preferirei redizionare il tutto oppure usare la print per scrivere su un file.

Comunque la nuova print ha anche diverse modalità di utilizzo: puoi anche specificare se andare a capo o meno, se usare un separatore (quello predefinito è lo spazio) ed eventualmente quale carattere.

Insomma, è stata anche potenziata.

L'unica cosa di diverso è che purtroppo si dovranno mettere le parentesi tonde per racchiudere gli argomenti: soltanto due caratteri in più non mi sembra un'esagerazione, a fronte dei vantaggi e della "linerarità" del linguaggio (sono sparite tutte le istruzioni "custom", come print, exec, ecc. Adesso sono tutte funzioni).

[~FullSyst3m~]

Originariamente inviato da cdimauro

Il fatto di avere print come funzione built-in permette di poterla eventualmente rimpiazzare.

Immagina di stare sviluppando un'applicazione e che ti serva visualizzare delle informazioni utili per il debugging. Usi la print normalmente e, quindi, vedi a video tutto ciò che ti serve. Poi devi andare in produzione, ma il codice con le print è rimasto ed è piuttosto fastidioso. Che fare? Semplice: si definisce una funzione che non fa nulla e la si rimpiazza al posto della print:

def NullPrint(*Args, **Keys): pass

install(print = NullPrint)

// Questa è una mia funzione built-in che permette di "installare" facilmente oggetti nel namespace dei bultin-in.
// In questo caso  rimpiazzerebbe la print con NullPrint che... non fa nulla

Questo tipo di situzioni è abbastanza comune, e in questo modo risolvo in maniera molto semplice.

Altra cosa: io generalmente preferisco loggare in un file quelle informazioni, per cui al posto di non farle fare nulla, preferirei redizionare il tutto oppure usare la print per scrivere su un file.

Comunque la nuova print ha anche diverse modalità di utilizzo: puoi anche specificare se andare a capo o meno, se usare un separatore (quello predefinito è lo spazio) ed eventualmente quale carattere.

Insomma, è stata anche potenziata.

L'unica cosa di diverso è che purtroppo si dovranno mettere le parentesi tonde per racchiudere gli argomenti: soltanto due caratteri in più non mi sembra un'esagerazione, a fronte dei vantaggi e della "linerarità" del linguaggio (sono sparite tutte le istruzioni "custom", come print, exec, ecc. Adesso sono tutte funzioni).

Ancora nel mio percorso di studi non ho incontrato queste situazioni sinceramente, anche perchè come sai il libro che sto studiando si riferisce ad una versione vecchissima di Python. Però ormai lo sto finendo e ho fatto già stampare e rilegare il tutorial ufficiale di Guido, lì sicuramente troverò cose più aggiornate e approfondite

[MasterDany]

La funzione prin è proprio scomoda...Oddio non cambia quasi niente però...

Mi fido di Guido!

[~FullSyst3m~]

Originariamente inviato da MasterDany

La funzione prin è proprio scomoda...Oddio non cambia quasi niente però...

Mi fido di Guido!

Dire che non cambia quasi niente mi sembra eccessivo. Leggiti la documentazione e vedi

[cdimauro]

Originariamente inviato da MasterDany

La funzione prin è proprio scomoda...

Suvvia: sono soltanto due caratteri in più.

Oddio non cambia quasi niente però...

Mi fido di Guido!

E fai bene perché di carne al fuoco ce n'è veramente PARECCHIA.

[MasterDany]

Originariamente inviato da cdimauro

Suvvia: sono soltanto due caratteri in più.

E fai bene perché di carne al fuoco ce n'è veramente PARECCHIA.

Non cambia quasi niente era riferito al print!

[~FullSyst3m~]

Originariamente inviato da cdimauro

Suvvia: sono soltanto due caratteri in più.

E fai bene perché di carne al fuoco ce n'è veramente PARECCHIA.

Sarà una gioia proprio andarsi a rivedere tutto

[variabilepippo]

Sarà una gioia proprio andarsi a rivedere tutto

E' quello che ogni sviluppatore deve fare per tenersi costantemente aggiornato sulle novità messe a disposizione dagli strumenti che utilizza, IMHO è una gioia, altrimenti farei altro.