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

[Enrico Franchi]

On Nov 12, 2009, at 12:52 AM, luigi scarso wrote:

> Sei in grado di riformulare il periodo
> "Lo scarterei..yakuza. "
> in un italiano piano lasciando
> perdere temini come bloated e
> paragoni come "si contano...yakuza"
> ?

Sono in grado di farlo. Non ho tuttavia intenzione di farlo.
Per inciso, sono due periodi. Se i problemi sono a questo livello....

> Quindi per favore riformula in modo piano
> il tuo periodo sopra.
> Nota:
> evita il comportamento "da maestrina inglese" di
> "Rileggi..Attentamente.. bloated"
> è un po' ...provinciale.
> Se pensi di essere stato frainteso riscrivi in modo chiaro e basta
> --forse non ha scritto in modo chiaro .
> Abituati a pensare che altre persone con altre tradizioni possono
> venire in questa ml,
> e non necessariamente sono idiote -- chiaro ?

Guarda, non e' questione di essere idioti: e' questione di leggere di
fretta. *Se* due periodi di cui uno di una riga e uno di due richiedono
di essere riformulati, mi dispiace, ma non ci sono i presupposti per il
resto della discussione: ritengo piuttosto probabile che da qualche
parte scappi un periodo di tre righe, specie considerando il wrap a
circa 72 caratteri. Infine, purtroppo, i termini inglesi sono in  
sostanza
uso comune e temo inevitabile.

> No scusami ma mi  perdo ...
> se la mia libxyz manifesta un baco io posso anche decidere di  
> mantenerla
> ma il progetto forse può andare....malino , ti pare ?

Se *devi* fare l'upgrade, *devi* farlo e lo farai in modo controllato.
Vorremo parlare di qualche baco di Python in specifico stiamo parlando
oppure la cosa e' accademica?

> Ed ancora : perchè parli di librerie ?
> Io parlo di linguaggio di programmazione , Python, meglio  CPython .
> Le librerie sono una storia diversa.

Tratta il compilatore/interprete allo stesso modo. Mi pare ovvio.

>> (che sviluppi su Zope)
> no, non sviluppo in zope .
> Lo uso , l'ho usato e  lo trovo ragionevole
> ma non sono uno sviluppatore Zope

Ehm, plone gira sopra zope.

>> Possiamo fare una
>> semplice deduzione riguardo al fatto che *forse* il problema  
>> riguarda Zope e
>> non Python?
> no -- si cioè deduci pure , ma è sbagliata.
>

E il problema di Python sarebbe? Che fanno una nuova versione e tu non
puoi non usarla?

BTW, vorresti che mi mettessi a fare il grammar troll come un tal Scarso
che gira per questa ML?


>
>
>
>> 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.
> Traduzione errata.
> Sei saltato di palo in frasca,
> da linguaggi a librerie . Io parlo di un mio disagio con il  
> linguaggio .
> Le librerie sono un altro aspetto dello sviluppo sw.

Guarda, quanto detto per una libreria, vale *anche* per un interprete  
o per
il compilatore. Quello era un *esempio*: il principio e' che gli  
strumenti di
sviluppo (quindi, librerie che usi, interpreti, compilatori, etc.) li  
aggiorni come
e quando dici tu.

Per il resto, dal momento che i programmi Python 2.4 girano su Python  
2.6...
dove sarebbe il problema?

>> E quindi che fava ti frega se esce la nuova versione?
> Per un linguaggio ? Fastidio

Ah, ok, una fisima.

>> Forse "pratica comune che con sane policy di gestione di progetto  
>> non rompe
>> le palle a nessuno"?
> Certo,  sottoscrivo nella sua generalità .
> Ma  è una affermazione appunto generica sempre valida.
> Non capisco cosa vuoi dire.

Vuole dire che, di fatto, il problema di cui parli non e' tecnico. E',  
come tu stesso
lo descrivi un tuo personalissimo fastidio.

>> Scusa, ma cosa ci possiamo fare noi se Zope prende ste scelte?
> Buona domanda...io ho protestato.

Vai a protestare con quelli di Zope.

>> Cosa c'entra il resto di Python.
>> Tu continui a parlare di Python,
>> ma avresti bisogno di s/Python/Zope/g.
> hmm.
> Non è cosi, cioè non tutti la pensano così, ed a ragione.
> http://www.muthukadan.net/docs/zca.html
> Zope Component Architecture (ZCA) is a Python framework for supporting
> component based design and programming. It is very well suited to
> developing large Python software systems. The ZCA is not specific to
> the Zope web application server: it can be used for developing any
> Python application. Maybe it should be called as Python Component
> Architecture.

Scusa, la possono anche chiamare oompa loompa component architecture,
cosa cambia il nome? E' una *libreria* (non parte della libreria  
standard). E
non e' nemmeno universalmente utilizzata come lasceresti intendere.

Vorresti spiegarmi quale e' il problema?


> Ora, io capisco il vs punto di vista (di python.it intendo)

Python.it non e' un organismo unitario. Ci sono tante persone che  
scrivono
su una mailing list. Concordia su un dato argomento e' puramente  
accidentale.

> Però.. non so . Python Component Architecture a me pare che coinvolga
> il linguaggio

No. E' una libreria, forse un framework. Che mi frega?

> Forse Python Component Architecture. poteva essere di aiuto qui ?
> http://blog.labix.org/2009/05/15/class-member-access-control-enforcement-vs-convention

Sono completamente in disaccordo con l'autore.


> Non so.
> In ogni caso : certe features possono essere introdotte con un
> approccio tipo ZCA ?
>
> Ma -- un momento:
> vorresti dirmi che visto che è ZCA ah beh allora non mi riguarda ?
> Tutta quella botta di sw testata, navigata  etc etc non te ne frega
> niente per i tuoi progetti ?
> CHE TI REINVENTI LA RUOTA IN PYTHON  PIUTTOSTO CHE USARE ZCA ?

Potrebbe essere che l'approccio di ZCA non mi piace? Anzi, di fatto non
e' nemmeno detto che i "problemi" che risolve siano problemi.
Ti diro' di piu', da quello che vedo, e' qualcosa che gioca molto male  
con
il resto delle librerie che uso (che invece mi piacciono e mi servono).

Di fatto l'unico pezzo di zca che ho usato e' zope.interface. E no,  
non mi piace.
Ma lavorando con Twisted salta fuori.

>
>
>>> No, parliamo che python è un linguaggio di sistema x linux.
>>
>> No. Python e' un linguaggio. Punto.
>> Poi viene usato anche per quello.
> Mi dispiace ma su questa cosa non scherzo.
> Riscrivo, ma non penso di essere stato ambiguo.
>
> Python è un linguaggio di sistema per  linux.

Guarda, mettilo pure in un loop infinito. Un *linguaggio* e' un  
*linguaggio*.

> Installare più versioni di Python in linux NON è semplice:
> prestate attenzione, potreste compromettere il vs sistema linux.

Se tu non sei capace di gestire la cosa, il problema e' tuo, non mio.
Installare piu' versioni di Python in Linux e' *facile*. Bisogna capire
appena qualcosa del sistema, ovvio.

Ti diro': considero *normale* avere piu' installazioni. Tipicamente  
quella
usata dai tool di sistema non posso e non voglio toccarla, viceversa  
quella
che uso io e' *precisamente* qualcosa su cui voglio controllo  
*completo*.

> E per essere chiari non sto parlando di CPython in Windows o Mac,
> non sto dicendo che installare Python *di per se* è difficile,
> non sto dicendo che compilare python è difficile
> no sto dicendo che non so installare python.

No, stai dicendo che ritieni di poter "compromettere il sistema" (per
qualche definizione di compromettere). Al che mi viene da chiedermi
se il problema e' che non ti sai muovere in un sistema Linux, se non
ti sai muovere con Python o cosa.

> E' una tua scelta -- che non posso condividere  perchè non mi è  
> chiara.

No, e' una scelta piuttosto comune. In effetti e' una pratica di  
gestione del
progetto parecchio diffusa e l'unica che ti garantisce perfetta  
riproducibilita'
(che tende a fare comodo per acchiappare bachi dei tuoi clienti).

> Non so cosa intendi con "strumenti di sviluppo installato in modo
> indipendente dalla piattaforma"
> ne "tutti" a chi/cosa  lo riferisci,
> ne l'uniformità a cosa la riferisci,
> ne cosa intendi per update incontrollato .

Hai quotato male. Non ho intenzione di sprecare ulteriori bytes  
riscrivendo
quello che ho gia' scritto.

> hey ma sotto dici che anche tu passerai a breve -- cosa ti fa credere
> di essere l'unico ?

Per le *mie* cosine. Quelle che potrei scrivere invece in scheme senza
presupporre che entro due anni scheme soppiantera' Python.

> No, e non è neanche uan mia definizione .
> "Leggermente differente" lo trovo una presa in giro.
> Meglio chi dice "completamente differente"

Si, buona notte, eh.

>> Non sto nemmeno considerando di migrare la roba seria prima di due  
>> anni,
>> al momento.
> 2anni ?--  mi sa che dovrai rivedere la tua timeline

proof missing.

> hm no, significa che ho visto ed ho scelto in modo consapevole di non
> occuparmene
> (come stai facendo tu ) fino al prossimo anno, che se guardi il
> calendario *non* sono 2anni ma 2 mesi.

Si, pensieri random in liberta'. Una filastrocca a questo punto  
sarebbe appropriata
per alzare il livello del discorso.

> si si si sono cosapevole e maturo --ma faccio finta di non aver visto
> quello che hai scritto . 2.7 ? sciò, pussa via brutta bestiaccia

Come sopra.

> Chi cura lo svliluppo del linguaggio CPython dovrebbe preoccuparsi
> delle conseguenze delle scelte su questi 2
> grossi progetti ?
> SI o NO ?
> Capisco che la maggior parte di voi dica NO.

No, manco per il cazzo. Python viene sviluppato. Le librerie e i  
progetti
che dipendono da Python faranno le loro scelte e fine della storia.

>
> Io ..non so.
>
> Un CMS stratosferico  ,

Diciamo orrendo...

> una suite Office libera con formato doc. normato ISO che usa gli  
> opentype,
> un linguaggio di programmazione **super** come python ,
> con ctypes + gcc ti estendi a sagemath ed R e Root  a quantalib..
> **GRATIS**

Scusa... ma tutto il mondo dovrebbe rimanere a Python 2.3 perche'  
OpenOffice
usa quello? Se sviluppi per open office, userai Python 2.3. E guarda  
caso,
quello che scrivi funzionera' anche fuori.

Non puoi pretendere che tutti rimangano a Python 2.3 perche' tu vuoi  
integrare il tutto
in OpenOffice.

> Ma vi rendete conto che potete connettere oocalc con sagemath e
> pubblicare su web
> -- e nessun spreadsheet al mondo vi darà mai  questo rapporto
> prestazioni/prezzo ?

E a me?

> E che questa cosa è semplicemente ingolfata da questioni di versioni
> del linguaggio ?

No: non e' una questione di linguaggio. E' una questione dei binding  
di open office.
Punto. Dopo di che, per dirla piana, non me ne frega un accidenti.
Se fossimo rimasti a Python 2.3, probabilmente avrei piano piano  
mollato Python.

Devi rompere le palle a quelli di open office che non si aggiornano.  
Meglio ancora:
devi rimboccarti le mani e dare una mano ad aggiornare PyUno a Python  
2.x.
Non devi pretendere che tutto il mondo rimanga indietro perche' un  
paio di progetti
che ti interessano hanno i loro problemi (e tipicamente il 90%  
dell'ecosistema Python
quei problemi non li ha).




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