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

[luigi scarso]

2009/11/11 Daniele Varrazzo <piro a develer.com>:
> On Wed, 11 Nov 2009 16:57:47 +0100, luigi scarso <luigi.scarso a gmail.com>
> wrote:
>> 2009/11/11 Daniele Varrazzo <piro a develer.com>:
>
>> lua + C == stabilità del linguaggio
>> lua non cambia nel tempo, e neppure C (beh, calma, tutto cambia)
>>
>> Ma ovviamente ti curi platform + threading, ovvero fine tuning della
>> tua application,
>> devi essere disciplinato per grossi progetti
>> e non è vero OO (beh lua è un po' quel che vuoi)
>> Insomma : STABILITA' del linguaggio anche rispetto ai cambiamenti
>> tecnologici

>
> Non considero la bellezza del linguaggio nella sua immutabilità. Il C mi
> piace, ma non PER la sua immutabilità (e infatti il C++ non mi piace perché
> non ha avuto il coraggio di separarsene quando ha potuto).





>Se avessi bisogno di stabilità in un
> progetto, stabilirei delle policy che lo riguardano, non sceglierei un
> linguaggio che ha deciso di concludere la propria evoluzione.
Boh.
Non c'e' nulla di male in un linguaggio che, come hai detto tu
"ha deciso di concludere la propria evoluzione",
basta che sia un "buon" linguaggio, vivo, insomma che ti serva per il
tuo progetto.
Vedi XML -- lo vorresti scartare perché è sostanzialmente stabile ?
La "stabilità"  di un progetto, come dici tu, e' più qualcosa di
policy, di requisiti, di team..
certo anche di linguaggio, ma suvvia
se usi un linguaggio che cambia ogni 3 giorni ti aspetti un progetto
che arriva alla fine ?
Alla fin fine non hai molto da scegliere dalla torta
Java,C,C++, C#


> E non sono
> neanche sicuro che LUA sia uno di questi
Guarda la Version history
http://www.lua.org/versions.html

> (forse sbaglio, ma credo la sua
> linea guida sia quello di avere un runtime leggero,
> per cui è probabilmente
> più indicato del Python in ambiente embedded, ma non lo considero
> esattamente uno scenario quotidiano - non il mio).
Si e no  puoi anche fare un tinypy
http://www.tinypy.org/

Lua puoi vederlo come "veramente poche cose, anzi quelle che ti servono e basta.
Il resto fattele"  IE no batteries included. In questo senso è stabile
-- c'e' poco quindi cambia poco.

>
>
>> CPython -- ok vai con l'acqua santa  -- cambia troppo per i miei gusti:
>> "CPython ?  QUALE CPython ? "
>> Guardate Plone: Plone4.0 avrà Python 2.6
>> ma il 3.3 ha il python 2.4 e la mia Ubuntu LTS ha il 2.5
>> Ora voi mi direte che non cambia nulla da 2.4 a 2.5 a 2.6
>> -- ed allora perché cambia numero ? Insomma vi capisco... ma non mi
>> piace, mi fa acidità
>> e quindi mi adeguo.
>
> Questi problemi con le diverse versioni del ramo 2.x di Python le ha avute
> solo Zope: è un suo problema specifico.
No, anche mio da un paio di mesi, da quando mi son chiesto "perchè
cambia così spesso" ?

>
> Io ho avuto il problema inverso del tuo: proprio perché un paio di anni fa
> volevo provare Zope non ho potuto usare Python 2.5 di sistema per un anno
> buono sulla mia Gentoo di allora. Non che fosse stato un vincolo
> insormontabile: diverse versioni di python possono coesistere senza alcun
> problema nella stessa macchina.
Si, su questo punto penso di essere il solo in Italia a pensare che
installare python
su una linux box non è na operazione da fare a cuor leggero.

Insomma è vero
diverse versioni di python possono coesistere senza alcun
problema nella stessa macchina.

come è vero che
diverse versioni di bash possono coesistere senza alcun
problema nella stessa macchina.

come è vero che
diverse versioni di perl possono coesistere senza alcun
problema nella stessa macchina.

certo , tutto vero.

Ma bisogna stare accorti, non credi ?


>Avrei potuto usare un 2.4+zope non da
> package, e penso che per lo sviluppo e la distribuzione di un sistema
> server (e una soluzione basata su Zope lo è, no?)
Boooh...
Se qualcuno pensa che ZCA ZopeComponenteAdapter
possa essere PythonComponentAdapter ...

>sia un approccio
> tranquillamente praticabile.
Mah  mica tanto tranquillamente per i server.
Io preferisco sempre usare la coppia Zope xyz e Python abc specificata nel sito.

>
> Il numero cambia perché il linguaggio si estende.
Già
>Cambia solo la seconda
> cifra perché la compatibilità col passato è largamente mantenuta.
largamente ? per gli usi odierni di python non mi basta

>Zope non
> usa python come linguaggio, lo usa come una specie di piattaforma e gli
> mette le mani direttamente nell'implementazione. Se tutta l'infrastruttura
> è basata su un leak implementativo è normale che non possa esserci
> evoluzione.
Uh -- non mi è chiaro.
>
>

>> Python 3,poi...,
>
> ...e quello è un altro discorso. Che puoi evitare tranquillamente, tanto
> in qualunque progetto usi più di 3 librerie di terze parti almeno una non è
> stata ancora portata. Python 3 è una possibilità per tutti e non è un
> problema per nessuno, tranne per chi decide di porselo.
Non è cosi.
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à
E la situazione non è come 1.5 , allora lo scenario era diverso --
oggi python è piu' importante.

La mia opinione ?
il ramo 2.6 frozen.
il ramo 3 doveva essere **COMPLETAMENTE** compatibile con il ramo 2.6 frozen.



-- 
luigi