[Python] "Go or Unladen Swallow? " Cosa ne pensate ?

[Enrico Franchi]

On Nov 11, 2009, at 8:16 PM, luigi scarso wrote:

> 2009/11/11 Enrico Franchi <enrico.franchi a gmail.com>:
>> On Nov 11, 2009, at 6:50 PM, luigi scarso wrote:
>>
>> Vedi XML -- lo vorresti scartare perché è sostanzialmente stabile ?
>>
>> Lo scarterei perche' e' bloated quasi peggio di Java...
>> tipicamente i casi in cui serve, si contano sulla punta delle dita
>> di un fallito yakuza.
> Uh-oh
> dove vedi questa gran schifezza e fallimento ?

Rileggi il periodo sopra. Attentamente. Il termine che ho usato io,
per inciso, e' bloated.

>> Se chi gestisce il progetto e' capace di gestire un progetto, si.
> Uh ?

Come sotto.

>
>> Perche' *normalmente* le versioni delle cose che usi non cambiano
>> mentre sviluppi in modo incontrollato: le congeli *tu*.
> un po' sconnesso logicamente
> *normalmente* fa a pugni col mio "ogni 3 giorni" -- è ovvio che non  
> è normale
> e *tu* non congeli niente. Tu usi una versione a (perchè stiamo
> parlando di linguaggi), mentre forse
> c'e' in giro la versione b.
> il termine frozen è forte : è prerogativa di una autorità  
> riconosciuta .
> Io non posso congelare python, ma forse Rossum si.
> Quanto ai tuoi  progetti, magari **pensi** di congelarli, in realtà  
> ti sei messo
> un una situazione di lento cambiamento.
> Ovvero se il cliente ti chiede qualcosa tu la fai, frozen o meno.
> Solo che sei stato bravo e tutte le richieste fino ad ora sono state
> gestibili in un ottica di micro cambiamenti. Ma non conosci tutti i
> requisiti futuri, quindi speri che la prossima
> richiesta non ti costringa a grossi cambiamenti -- o rispondi al tuo  
> cliente
> "sorry it's frozen" ?
>

Ma cosa stai dicendo? Quando tu dirigi un progetto *tu* stablisci le  
versioni
delle librerie che utilizzate. Punto e semplice. Se fai update a  
random degli
strumenti di sviluppo, il team ha dei problemi. non si fa, punto e  
basta.

Per inciso, guarda, qua sviluppiamo tutti in Python, e tutti sti  
problemi, apparentemente
li hai solo tu (che sviluppi su Zope) e quelli che sviluppano in Zope.  
Possiamo fare una
semplice deduzione riguardo al fatto che *forse* il problema riguarda  
Zope e non Python?

Traduzione: se io uso libfoo 5.0 ed esce libfoo 6, sta a *me* decidere  
se passare a libfoo 6,
lavorare con entrambe o mantenermi con la 5. Punto e fine: se non lo  
faccio, il problema e'
mio.

Ti confesso... introdurre libfoo 6, con un minimo di scm non e'  
normalmente e sperabilmente
un bagno di sangue.



>
>
>> Quando e se si decide per l'upgrade, lo si fa. Ma se non e'  
>> necessario,
>> non lo si fa.
> Si, e non mi pare una grande rivelazione.

E quindi che fava ti frega se esce la nuova versione?

>> Parliamo di C#? Quello di C# 2, 3, 3.5, etc etc etc? Con le class- 
>> library
>> pure in aggiornamento?
> e quindi ?
> Aspetta  mal comune mezzo gaudio ?


Forse "pratica comune che con sane policy di gestione di progetto non  
rompe le palle a nessuno"?
.
> Boh, io sto parlando di python.
> La numerazione di Zope è già illogica di suo :
> "abbiamo chiuso Zope3. Zope2 continua. Ma non preoccupatevi :
> c'e' five."
> Ah si, scusate, i numeri sono una opinione...

Scusa, ma cosa ci possiamo fare noi se Zope prende ste scelte?
Cosa c'entra il resto di Python. Tu continui a parlare di Python,
ma avresti bisogno di s/Python/Zope/g.

>> Se per "stare accorti" utilizzare il cervello, sono d'accordo.
>> Ma non mi vengono in mente molte cose che uno sviluppatore
>> puo' fare senza accendere il cervello.
>
> No, parliamo che python è un linguaggio di sistema x linux.

No. Python e' un linguaggio. Punto.
Poi viene usato anche per quello.

> E far passare l'idea  "installare più versioni di python è semplice "
> è sbagliata .
> Bisogna dire il contrario: "installare più versioni di python NON è  
> semplice "
>
> Scusa ma su questo punto non scherzo.

Mi dispiace per te che non lo so fare, che dirti. Secondo me qualcuno  
qua
che trova il tempo di spiegarti come fare lo trovi pure.

Aggiungo... io come policy gli strumenti di sviluppo me li installo  
*sempre* in modo
indipendente dalla piattaforma. Perche' non tutti usano stesso OS etc  
etc etc e si vuole
invece uniformita'. Non si vuole che un update incontrollato del  
sistema comprometta
qualcosa, per dire.

Per me, posso dire, avere piu' versioni di Python installate e'  
assolutamente la norma.

>> Attualmente abbiamo 2 rami Python non compatibili  e vivi (anzi 3  
>> rami
>> : io ho un server anche con python 1.5.2 , ma te lo abbono)
>> 3.0 ?
> *Tu* lo puoi evitare, tanto lui ti troverà

Sei in loop.

> Ma va, dove vivi, mi ha già trovato.
> In fontforge si usa python 2 parecchio
> ma stanno già pensando al 3 -- completamente differente.

Una rondine fa primavera?

BTW, il "completamente differente" non ti pare un po' forte?


Poi *IO* passero' a breve, fuor di produzione, a Python 3. Per farmi  
trovare
pronto *e* perche' molte delle novita' mi piacciono seriamente.
Non sto nemmeno considerando di migrare la roba seria prima di due anni,
al momento.

>> Quindi di fatto non hai ben chiaro quale sia il punto di Python 3.
> DELIBERATAMENTE
> non lo voglio sapere niente di 3 fino all'anno prossimo.
> Mi è bastato il teatrino "3.0 ? non esiste più !"

Ok, quindi stai "DELIBERATAMENTE" parlando di qualcosa che non hai  
presente.

>
>> In particolare sai che ci sara' anche Python 2.7?
> Si -- cioè no  faccio finta di non avere visto niente in merito.  2.7
> alpha ? sciò, pussa via.

Sei consapevole che da alpha diventera' beta e da beta stabile e che  
non c'e' intenzione
di finire la serie 2.x con 2.6?

> Per me quando Plone4.0  va a 2.6.x , OO va su 2.6.y  sono più che  
> felice
> Il resto è abbastanza aria fritta.

Poi il giorno in cui chiarirai perche' tutto l'ecosistema python  
dovrebbe dipendere da
questi due progetti...


-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: http://lists.python.it/pipermail/python/attachments/20091111/9babc38f/attachment-0001.htm