Su quale versione di Python (2.4, 2.5, 2.6, 3.0) standardizzi per gli sforzi di sviluppo della produzione (e perché)?

Question

Nel nostro gruppo eseguiamo principalmente l'architettura dei motori di ricerca e il lavoro di integrazione dei contenuti e la maggior parte di tale base di codice è in Python. Tutti i nostri strumenti di compilazione e le dipendenze del modulo Python sono nel controllo del codice sorgente, quindi possono essere verificati e l'ambiente caricato per l'uso indipendentemente dal sistema operativo / piattaforma, in qualche modo simile all'approccio virtualenv utilizza.

Per anni abbiamo mantenuto una base di codice compatibile con Python 2.3 perché uno dei prodotti commerciali che utilizziamo dipende da Python 2.3. Nel corso degli anni ciò ha causato sempre più problemi poiché gli strumenti e le librerie più recenti richiedono versioni più recenti di Python da quando è uscito il 2.3 nel 2004.

Di recente abbiamo disaccoppiato il nostro ambiente di costruzione dalle dipendenze dall'ambiente del prodotto commerciale e possiamo usare qualsiasi versione di Python (o Java) che desideriamo. È passato circa un mese da quando abbiamo standardizzato su Python 2.6 come la versione più recente di Python che è retrocompatibile con le versioni precedenti.

Python 3.0 non è un'opzione (per ora) poiché dovremmo migrare troppo della nostra base di codice per far funzionare di nuovo correttamente i nostri strumenti di compilazione e integrazione.

Ci piacciono molte delle nuove funzionalità di Python 2.6, in particolare i moduli migliorati e cose come i decoratori di classe, ma molti moduli da cui dipendiamo fanno sì che l'interprete Python 2.6 emetta vari avvisi di ammortamento. Un altro strumento a cui siamo interessati per la gestione dei nodi del cluster cloud EC2, Supervisor non funziona nemmeno correttamente con Python 2.6.

Ora mi chiedo se dovremmo standardizzare su Python 2.5 per ora invece di usare Python 2.6 nello sviluppo di strumenti dell'ambiente di produzione. La maggior parte degli strumenti desiderati / necessari sembra funzionare correttamente con Python 2.5. Stiamo provando a risolvere questo problema ora prima che ci siano molte dipendenze dalle funzionalità o dai moduli di Python 2.6.

Molte grazie!

-Michael

Answer 1

Non abbandonerei 2.6 solo a causa degli avvisi di deprecazione; quelli scompariranno nel tempo. (Puoi usare l'opzione -W ignore per l'interprete Python per evitare che vengano stampati, almeno) Ma se i moduli che devi usare in realtà non funzionano con Python 2.6, sarebbe un motivo legittimo per rimanere con 2.5. Python 2.5 è ampiamente utilizzato ora e probabilmente lo sarà ancora per molto tempo (considera quanto è durato 2.3!), Quindi anche se vai con 2.5, non sarai costretto ad aggiornare per un po '.

Uso Python 2.5 per tutto il mio lavoro di sviluppo, ma solo perché è la versione disponibile nel repository di pacchetti di Gentoo (Linux). Quando i manutentori di Gentoo dichiareranno Python 2.6 "stabile" * , passerò a quello. Naturalmente, questo ragionamento non si applica necessariamente a te.

* Python 2.6 in realtà è stabile, il motivo per cui non è dichiarato tale in Gentoo è che Gentoo si affida ad altri programmi che dipendono da Python e non sono ancora aggiornati per funzionare con 2.6. Ancora una volta, questo ragionamento probabilmente non si applica a te.

Answer 2

La mia azienda è standardizzata in 2.5. Come te, non possiamo passare al 3.0 per un milione di motivi, ma vorrei tanto poter passare al 2.6.

Facendo la programmazione giorno per giorno, cercherò attraverso la documentazione e troverò esattamente il modulo o la funzione che desidero, ma poi avrà la piccola annotazione: Novità nella versione 2.6

Direi di andare con la versione più recente, e se si aprono avvisi di ammortamento (probabilmente ce ne saranno pochissimi), basta cercare un modo migliore per farlo. Complessivamente il tuo codice sarà migliore con 2.6.

Answer 3

Per me il più importante da rispettare con Python 2.5+ è perché supporta ufficialmente ctypes , che ha cambiato molti sistemi di plugin.

Sebbene sia possibile trovare i tipi con cui lavorare con 2.3 / 2.4, non sono ufficialmente raggruppati.

Quindi il mio suggerimento sarebbe 2.5.

Answer 4

Per ora stiamo rispettando la 2.5.2. Il nostro stack tecnologico è incentrato su Django (ma abbiamo una dozzina di altri bit e bob). Quindi restiamo vicini a ciò che fanno.

Abbiamo dovuto tornare a docutils a 0.4 in modo che funzionasse con epydoc 3.0.1. Finora, questo non è stato un grosso problema, ma potrebbe, ad un certo punto, farci ripensare al nostro uso di epydoc.

L'aggiornamento 2.6 fa parte del nostro piano di sviluppo. Al momento disponiamo di un budget, ma non di un programma fisso.

L'aggiornamento 3.0, allo stesso modo, è qualcosa che ricordo alla gente. Dobbiamo budget per questo. Quest'anno non lo faremo a meno che Django non passi alla 3.0. Potremmo farlo l'anno prossimo.

Answer 5

Penso che la soluzione migliore sia quella di rinunciare alla speranza sull'uniformità totale, anche se avere un ambiente comune è qualcosa su cui lottare. Ti troverai sempre di fronte a problemi di versione, ad esempio durante l'aggiornamento alla prossima versione dell'interprete migliore.

Quindi, invece di affrontarlo in base al problema, potresti risolvere questo problema dando una buona occhiata alla tua gestione delle versioni.

Invece di rilasciare i sorgenti, scegli binari dipendenti dalla piattaforma (oltre alla distribuzione dei sorgenti).

Quindi, ciò che fai è definire un numero di CPU supportate, ad esempio: x86-32, x86-64, sparc

Quindi quali sistemi operativi: Linux, Windows, Solaris, FreeBSD

Per ogni SO supportate alcune delle loro versioni principali.

Il prossimo passo è fornire binari per tutti loro.

Sì, in effetti ciò richiederà un certo investimento in infrastrutture e la creazione di edifici automatici dai tuoi repository (ce l'hai?)

Il vantaggio è che i tuoi utenti hanno solo una "cosa" da installare e puoi facilmente cambiare versione o anche mescolarne una. In realtà puoi anche usare diversi linguaggi di programmazione con questo approccio senza influire troppo sulla gestione delle tue versioni.