Newsgroup: it.comp.macintosh
Titolo: leopard: ruby python svn... tutte belle cosine, ma

non mi pare che abbiano annunciato la cosa piu' importante: 
ovvero che queste cosine vengano aggiornate: il 10.4.8 monta tuttora
python2.3.5 esattamente come il 10.4.0 18 mesi fa...
bah 

 python2.3.5 esattamente come il 10.4.0 18 mesi fa...
Semplicemente perchè è complesso cambiare la versione di Python o che
sotto le gambe dato che è usata dai loro strumenti. Per la nuova
versione "built-in" devi aspettare Leopard. Puoi sempre installartela a
mano.
-- 
Lawrence - 
http://www.oluyede.org/blog
http://www.neropercaso.it
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

 mano.
Anche perchè si installa con un doppio click.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 python2.3.5 esattamente come il 10.4.0 18 mesi fa...
E' voluto (o almeno mi sembra di ricordare cosi'). L'idea e' questa: un
miniupdate che cambia la terza cifra non dovrebbe causare alcun
problema agli utenti. Se io uso una feature di una versione vecchia di
Python non voglio "scoprire" dopo l'update che ora non funziona piu'
nulla!
Considera anche che la Apple ha una reputazione di essere user
friendly, non puoi star li a cambiarli tutti i programmi ogni due mesi!
Come esempio prendi gcc: utilissimo, ma proprio per quello non deve
cambiare.
Se sei il tipo che vuole avere l'ultima versione di Python,
probabilmente sei anche il tipo che se la sa' installare per conto suo.
Diego

 Diego

 mano.
si grazie lo so, quello che volevo dire e' che non c'e' nessun vantaggio
ad avere preintallate delle versioni che sai gia' che saranno freezate
(con bachi e tutto) e che dovrai affiancarle a quelle + recenti

 Anche perchè si installa con un doppio click.
gia' ma allora dimmi perche' mettere quella congelata? per il vantaggio
di averne2? che culo!

 cosa c'e' di complesso?
Gestire la compatibilita' con i pacchetti di terze parti.
Ciao
Mirko

 python2.3.5 esattamente come il 10.4.0 18 mesi fa...
non e' mai bello togliere il pavimento sotto ai piedi. Qualcuno le
usera' ancora nei suoi pacchetti non credi?
-- 
http://www.emeraldion.it
Donde guardo las miradas que me diste alguna vez
Donde guardo las promesas, donde guardo el ayer

 pure riavviare la macchina a' la' windozze...
il quicktime e' robba loro, non e' proprio il paragone piu' efficace...


 il quicktime e' robba loro, non e' proprio il paragone piu' efficace...
il gcc non e' loro pero', pur non portando avanti la seconda cifra, i
bachi glieli correggono...
meglio come paragone?

 wrote:

se e' un problema, seriamente, python sta messo malino assaje...

 usera' ancora nei suoi pacchetti non credi?
mi sfugge quale essenziale caratteristica, di cui tutti i pacchetti di
terze parti fanno largo uso, e' stata buttata alle ortiche in questi 2
anni di sviluppo python (se davvero c'e' allora e' python che sta messo
malino)

 (con bachi e tutto) e che dovrai affiancarle a quelle + recenti
Hai idea di come funzioni Debian vero? Per farti un esempio intendo...


 sti linguaggetti da scripting eh
Veramente esce una release ogni 18/20 mesi di Python, non è proprio cosi
veloce. Certo avrebbero potuto passare al 2.4 in questi 3 anni, ma
avranno avuto le loro motivazioni dato che come fai notare altri
software li cambiano più in fretta.
Probabilmente in futuro sarà cosi, dato che Python entra sempre più nel
parco software di OSX


 meglio come paragone?
decisamente peggio. GCC e' uno strumento per sviluppatori, sarebbe (a
parte necessita' specifiche) insensato utilizzare un compilatore
vetusto.
Diverso il caso delle librerie sulle quali devi invece garantire che
giri il piu' ampio spettro di applicazioni possibile.


 malino)
Non ce ne sono proprio perché il problema, se c'è, è di Apple non di
Python. Magari hanno delle patch che non hanno alcuna voglia di portare
al 2.4, magari avran fatto quattro conti e non vedono vantaggi dal
testare Python 2.4 su tutte le configurazioni per rilasciarlo ai clienti
ora che staranno testando il 2.5 per Leopard. Perché non chiedi
direttamente a loro?


 di averne2? che culo!
Perchè nessuno sano di mente si aspetta un cambiamento di major versione
pesante di un sw all'interno di un sistema.
Se vuoi parliamo della mancanza di MacOS X riguardo un sistema di
pacchetti: per il resto passare da Python 2.3 a Python 2.5 all'interno
di Tiger avrebbe portato solo potenziali problemi. Chi vuole il 2.5 fa
un doppio click. Punto.
Tanto discutere con te è come discutere con un muro.


 probabilmente sei anche il tipo che se la sa' installare per conto suo.
Anche perchè è un doppioclick.


 retrocompatibilità *anche* per questo).
Questo rischio c'é, per questo in genere ci sono varie versioni dei
moduli C distribuite per ogni versione.


 giri il piu' ampio spettro di applicazioni possibile.
python e'... una libreria? toh!

 direttamente a loro?
faccio cortesemente notare che il 2.4 e' gia' fuori da un pezzettino (24
mesi per la precisione con un anticipo di 6 su tiger)... vedi tu

 Anche perchè è un doppioclick.
e' un doppioclick ma e' anche da rifare girare le distutil su tutti i
package quello che si diceva sopra appunto, 

 Tanto discutere con te è come discutere con un muro.
d'altra parte anche le tesi di chi sa solo dire che si scrudappano le
applicazioni di terze parti fanno il paio ai colabrodi
mi pare di vedere ste applicazioni di terze parti che hanno tutte
versioni diverse per panther e per tiger... (che non hanno la stessa
versione di python eh!) e poi quando avremo leopard faranno 3 versioni?
ma di cosa stiamo parlando quali sarebbero ste preziose applicazioni di
terze parti che si scrudappano?

 parco software di OSX
oh, cominciamo a ragionare, una mezza ammissione che sarebbe
desiderabile un po' piu' di cura di quello che distribuiscono nel loro
os?
deo gratias

 moduli C distribuite per ogni versione.
versione major (seconda cifra)?

 os?
Ma non capisco qual č il punto del tuo thread. Che vuoi dimostrare? Che
ad Apple possono fare le cose meglio? Ci mancherebbe!


 mesi per la precisione con un anticipo di 6 su tiger)... vedi tu
Ripeto: chi se ne frega. A loro Python serve per far andare le loro
applicazioni, non di certo per far sviluppare te. Hanno avuto un ruby
buggato per millenni, cosa che non cambiava nulla agli utenti finali. Si
presume che un programmatore sappia installare e configurarsi la cosa.
Non li giustifico, ma me ne frego dato che non vedo il problema. MS
distribuisce OpenGL 1.2 mi pare, direi che a chiunque interessino le
OpenGL ce la possa fare a installarsi l'ultima versione o bisogna
lamentarsi anche di questo? Direi che i problemi in questi sistemi
operativi sono altri (tipo il sistema di packaging mancante)


 versione major (seconda cifra)?
Si.


 ad Apple possono fare le cose meglio? Ci mancherebbe!
non voglio dimostrare nulla, solo gettare una docciata di realismo sull'
eccesso euforico di ottimismo che mi pare d'avere letto ultimamente
apple ha una bella piattaforma che purtroppo tiene curata per la parte
dei luccichini... a chi interessa piu' la sostanza spesso tocca
sgrullarsi tutto a manella (con un sacco di idioscinrasie rispetto a
vari altri *nix) tutto qui
il fatto che mettano questo e quello non sta (fino a prova contraria) a
dimostare che poi se ne curino...

 operativi sono altri (tipo il sistema di packaging mancante)
non mi pare di avere negato questo problema

 vari altri *nix) tutto qui
Lo so bene, Linux è sicuramente più developer friendly secondo me. Gli
OSX Intel sono decisamente un passo avanti rispetto ai problemi della
roba PPC


 installare e rimpacchettare tutte le macchine dei clienti
Tanto lo si fa dalla notte dei tempi. Fare affidamento su cosa
*potrebbe* avere il cliente non è mai una saggia decisione (vedi il
problema dei browser)


 roba PPC
visto che non pianifico un ppc prima di almeno un annetto, fammi venire
un po' di sana invidia... in che cosa sono precisamente meglio?

 problema dei browser)
beh se apple mantenesse quegli oggetti aggiornati, si tratterebbe di
dire di fare un aggiornamento
ok ok voliamo troppo alti eh?
(il problema dei browser e' diverso si tratta di malizia non negligenza)

 un po' di sana invidia... in che cosa sono precisamente meglio?
Trovi più codice opensource funzionante ad esempio (almeno quello che ti
devi compilare) e in genere sembra che i produttori di software
preferiscano far roba per Intel che per PPC


 preferiscano far roba per Intel che per PPC
scusa eh, ma se me lo devo compilare... va sia su ppc che su intel
(assembler a parte, ma non mi e' mai successo)

 (assembler a parte, ma non mi e' mai successo)
Eh eh io ho un amico che tira madonne ogni volta perché questo o quel
driver non va su PPC (c'è anche da dire che lui usa Linux su un iBook,
insomma un pò se le cerca :P)


 insomma un pò se le cerca :P)
ahhhh ma credo sia tutta un altra minestra... i driver qui li fornisce
mamma apple eh ;)

 mamma apple eh ;)
Uliano,  Lawrence ha fatto il bravo ed ha registrato MacSOUP. Ora tocca
a te.. 181 giorni... dai....

, e poi
seguendo grandi quantita` di link da esse), visto che la discussione
sembra svolgersi nella totale ignoranza di queste discipline.
Supponendo che i principi delle discipline in questione siano a grandi
linee noti, riassumo...:
Il problema della retrocompatibilita` esiste _sempre_: quando vi e` un
qualsiasi cambiamento di "livelli inferiori" (anche un bug fix o una
semplice ottimizzazione) _potrebbero_ "rompersi" livelli superiori dello
stack, anche se la "rottura" puo` essere in realta` il "rivelarsi" di
difetti che gia` erano presenti nei livelli superiori e vengono
solamente "rivelati".  Ad esempio, una ottimizzazione puo` rivelare una
"condizione di corsa", un grave bug che era gia` presente (ma latente)
nell'applicazione ma non causava mai problemi reali perche` (prima
dell'ottimizzazione) l'operazione X risultava sempre piu` lenta
dell'operazione Y; similmente rimuovere il bug Z puo` rompere una
applicazione che involontariamente _contava_ sugli effetti del bug -- di
nuovo, si tratta di rivelare un bug latente nell'applicazione, ma dal
punto di vista dell'utente finale cio` non e` gran consolazione;-).
Dal punto di vista dell'utente finale, "ho messo l'ultimo aggiornamento
di MacOSX e l'applicazione FOO non funziona piu`" e` sempre un problema,
sia che l'aggiornamento abbia un bug, sia che l'aggiornamento si limiti
a "rivelare" bug che gia` erano latenti in FOO ma in pratica non
causavano nessun problema reale: la differenza fra questi due casi e`
cruciale per chi sviluppa e rilascia software (perche` correggere il
problema e rendere FOO nuovamente in grado di funzionare puo` richiedere
approcci assai diversi), ma non per chi lo usa.
Chi e` responsabile di rilasci e aggiornamenti per software "di basso
livello" (qualsiasi "piattaforma", particolarmente una sulla quale altri
sviluppatori indipendenti possono aver costruito livelli superiori) deve
dunque bilanciare il desiderio di diffondere bug-fix, ottimizzazioni,
ecc, con il desiderio della _stabilita`_, che in pratica si puo`
ottenere in modo *totale* solo ed esclusivamente lasciando in pace i bit
esistenti (cioe` non facendo _nessun_ aggiornamento:-).  Diverse
piattaforme fanno in merito scelte diverse: ad esempio, Debian "stable"
e` quasi mitico per la sua scelta pesantemente orientata alla
stabilita`, mentre altre distribuzioni come Ubuntu fanno scelte molto
diverse.  Si possono benissimo anche avere strategie diverse per diversi
componenti di una piattaforma vasta ed articolata, perche` le esigenze e
i tradeoff possono cambiare da un componente all'altro.
Io, professionalmente parlando, non sono ne` sono mai stato un "release
engineer", ma lavoro spesso a stretto contatto con releng, conosco a
fondo i problemi e le tecniche del settore, e ho in massimo rispetto per
la professionalita` dei release engineer; mi pare che in questa
discussione si siano ripetutamente ignorate troppe considerazioni
techniche relative a questa importante disciplina.
Alex

 certo, a parte la  INELEGANZA delle versioni multiple
Nella prossima versione, Ruby (per fare un esempio), sara' un
Framework. Cosi' potranno coesistere nello stesso sistema piu' versioni
e tutti saranno contenti. Forse faranno qualcosa di simile per Python,
gcc, etc..., non so, ma fino ad allora, bisogna accettare le rischieste
di chi non vuole upgradare ogni due mesi.
Diego

 terze parti che si scrudappano?
Quelle che uno può avere installato. Oppure le librerie. Non importa che
siano cose poco diffuse: Apple non può (o meglio non dovrebbe) fare
aggiornamenti che rischiano di rompere le cose.
Specie di una cosa come Python: se ti interessa la versione aggiornata
una scimmia sapiente è in grado di aggiornare, se non sai manco che c'è
e non ti interessa, stai benissimo con la vecchia.


 package quello che si diceva sopra appunto, 
Si vero. D'altra parte come vedi non ci sono alternative: il piů che
Apple potrebbe fare č automaticamente installarti una nuova versione (ma
lasciandola *non* di default). Insomma, il lavoro che potrebbero fare
legittimamente sarebbe quasi nullo.
Per fare 'the whole thing' ci vorrebbe un sistema di pacchetti decente.


 linee noti, riassumo...:
Io ho solo scritto cose specifiche, non legate al problema specifico:
ovvero che usando una feature vecchia di Python non č che passando al
nuovo si rompa il codice.
In sostanza sto asserendo che Python non č come altri linguaggi che
cambiando release rompono uno sfracello di codice diciamo a livello
'sintattico/semantico' (in generale semantico).
Non sto parlando dei problemi cui hai accennato, e sui quali sono in
sostanziale accordo con te (come ho scritto -- anche se in maniera meno
completa -- in altri parti del thread). Non ho reso la cosa abbastanza
chiara, ma alla frase 
"Se io uso una feature di una versione vecchia di
Python non voglio "scoprire" dopo l'update che ora non funziona piu'
nulla!"
mi ha fatto venire in mente una cosa tipo che Python 2.n (con n>3) abbia
sintassi/semantica non compatibile con il 2.3, per cui il codice va
riscritto. Cosa che invece č molto pubblicizzata dalla comunitą Python
(quando ho iniziato mi ricordo che si asserivano 5 anni di
retrocompatibilitą sui sorgenti).
Siccome altrove la frase 'Python č una palla' asserita da un noto troll
stava dissuadendo un possibile utente, ho preferito specificare questo
punto.


Pennellone Manicone <sp...@spennellamentoNOSPAM.it> wrote:

molti di piu', questi sono quelli da quando ho cancellato le pref
l'ultima volta
per principo non registro un sw che non viene sviluppato
l'amichetto friz ci metta buona volonta' e magari se ne parla, ma mac
soup e' quasi abandonware...

 Per fare 'the whole thing' ci vorrebbe un sistema di pacchetti decente.
eh che casino, porca eva...

 Diego

 e non ti interessa, stai benissimo con la vecchia.
il tuo ragionamento e' simmetrico al mio non vedo perche' il tuo punto
di vista debba essere necessariamente vantaggioso
in pratica avere il python ufficiale vecchio ha creato una sostanziosa
serie di alternative per l'updatamento (me ne vengono in mente almeno 5)
con sostanziale scorno di chi cerca di creare pacchetti semplici da
installare (ci sono pacchetti  che vanno solo su specifiche versioni di
alcune di queste alternative)
se apple ne tenesse una ufficiale *ragionevolmente* aggiornata chi
pacchettizza la roba sarebbe *costretto* a riferire il suo prodotto a
quella corrente 

 da 6 dico 6 mesi...
Boh, questo non lo so. Pero' le prime versioni sono generalmente un po'
buggate, no? O forse non e' cosi' con Python? Considera che l'OS deve
essere finito qualche settimana (mese?) prima dell'uscita ufficiale.
Poi considera che loro devono testarlo un minimo. Alla fine, quando
avranno iniziato ad aggiungere il nuovo Python, la versione 2.4 forse
era uscita da solo un mese o due, e non si sono sentiti di aggiungere
qualcosa di cosi' nuovo.
Giusto un'idea cmq, buttata li'. Non conosco Python e meno che meno il
loro sviluppo, e non ho informatori dentro alla Apple.
Diego

 essere finito qualche settimana (mese?) prima dell'uscita ufficiale.
sempre una giustificazione pronta per il comportamento apple?
alla fine a me pare che facciano solo cose a cazzo

 punto.
OK, ma personalmente vorrei evitare di "promettere" per conto di Python
qualcosa che non puo` mantenere, come l'ASSOLUTA portabilita` fra
release diversi (quella senza "quasi":-): se uno ci si mette di buzzo
buono, con bug sufficientemente sottili e/o utilizzo di "angolini" molto
particolari come quelli che ho teste` esemplificato, _riesce_ a scrivere
un'app in Python 2.3 che non funzionera` con 2.4, ecc.  Il 99.99% del
codice puo` non soffrire di questi problemi, ma, per quanti "nove" uno
impili, non sara` mai il 100%.  Ovviamente, valgono considerazioni
"almeno" equivalenti per qualsiasi altro linguaggio, libreria,
framework, device driver, o altro componente ai livelli inferiori dello
stack (molti, troppi componenti del genere vengono aggiornati e
rilasciati senza neppure una frazione della cura per la compatibilita`
col passato che usiamo in Python da qualche anno...).
Alex

 soup e' quasi abandonware...
E allora abbandonalo. Se lo usi, invece, vuol dire che ne accetti tutte
le features che ha al momento. Ed allora, pagalo. Sii coerente.

 gcc 3.2.2. E ti assicuro che o gli dai una buona raggione per cambiare,
RAGGIONE? Cosa è un raggio enorme? Fai una cosa per l'umanità intera,
ritirati dall'Uni... ma va va

 python2.3.5 esattamente come il 10.4.0 18 mesi fa...
e delle libcrypto e libssl ferme alla 0.9.7 dopo i recenti bug trovati?
d

 le features che ha al momento. Ed allora, pagalo. Sii coerente.
"a foolish consitency is the hobgoblin of little minds"

 "a foolish consitency is the hobgoblin of little minds"
E' proprio il tuo caso mi sa. REGISTRA MACSOUP.

 (io lo so, il che' e' tutto dire)
Non necessariamente. Applicazioni qualunque possono usare in qualche
loro parte Python.


> sempre una giustificazione pronta per il comportamento apple?
Senti, te hai chiesto una spiegazione: che ti aspettavi che dicessi? Ho
cercato di spiegare quale credo sia la logica.
Secondo me non e' un fatto di giusto o sbagliato come la metti tu. Come
altri hanno detto il giusto equilibrio fra stabilita' ed un prodotto
all'ultimo grido e' una decisione che fa' il produttore. E non c'e' una
risposta corretta.
Se Apple avesse preferito un'altro compromesso fra queste diverse
necessita', io t'avrei dato la stessa spigazione. Cosi' come uno la
puo' usare ugualmente per Debian o Ubuntu. Ognuno ha il suo target, e
su quella base decide.
Te volevi una spiegazione e quella ti e' stata offerta da molti. Se
invece vuoi un'opinione personale su cosa uno preferiresce allora
questa e' un'altra storia. Ma non cercare di vedere fantatismi li' dove
non ce ne sono.
Diego

 wrote:

ripensandoci anche un sistema di pacchetti decente ti scrudappa tutto
quello che ti sei sistemato tu a manella... mi sa che e' proprio bacato
il python e le sue distutils (come concetto eh... non che ha dei bugs)

 loro parte Python.
tutte con estensioni c? perche' se non manco se ne accorgono
ma allora cazzo se alla fine dobbiamo compilare sempre estensioni c
tantovale scrivere in c <g>

 E' proprio il tuo caso mi sa. REGISTRA MACSOUP.
registrati stocazzo
ciao e vaffanculo

 wrote:

guarda che io non volevo nessuna spiegazione: il mio era solo un
commento, altri si e' affrettati a spiegare e giustifacare la mammina ;)

 registrati stocazzo
Perfetta dichiarazione d'intenti. Benone. Auguri.