Newsgroup: it.comp.programmare
Titolo: Python

Anche noi lo utilizziamo nella ns. ditta!!! Mi sono informato da un mio 
collega a cui ho visto il manuale aperto...
Il suo uso in alcuni nostri script "accessori" lo rende pari a circa lo 
0.1% delle linee di codice da noi prodotte (90% C++, 9.9% VB e Perl).
Mi sento proprio "Industrial Light & Magic"!!!
PS: il linguaggio in se non è male.
PS2: basare la strutturazione sull'indent è quanto meno discutibile.
PS3: potete anche aver lavorato al "Daystrom Institute" su Utopia 
Planitia, ma queste sono mie opinioni che propongo con "forza".
-- 
Luc.

 PS2: basare la strutturazione sull'indent è quanto meno discutibile.
Cazzata (al solito).
--------------------------------
Inviato via 
http://usenet.libero.it

 Cazzata (al solito).
Per te (al solito).
-- 
Luc.

 Per te (al solito).
Apri gli occhi: guardati intorno. Sei chiuso in un angolino e continui a
sbraitare.
Va a "programmare", su... il tuo 5% sta gia' cominciando a farmi venire i
conati.


 conati.
[TROLL ON] (quando ce vo, ce vo)
  Sei alla frutta!!! Non ti darò scampo, finche non mi darai ragione!!!!!
  UAH UAH UAH!!!!!!
[TROLL OFF]
-- 
Luc.

 circa lo 0.1% delle linee di codice da noi prodotte 
Questo dimostra,se non altro, che il codice python (anche grazie 
all'uso dell'ident per la struttura) è molto compatto :)
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 Non mi sembra. Azimuth ti sta spaccando i dentini... ;-PPP
Davvero ? io direi il contrario.


 all'uso dell'ident per la struttura) è molto compatto :)
Se poi lo comprimi, lo e' ancora di piu' (ma che razza di discorsi sono?).
*** Azimuth ***

 Davvero ? io direi il contrario.
Ovvio[1].
*** Azimuth ***
[1] "Oste, com'e' il vino?" "Ottimo!"

 [1] "Oste, com'e' il vino?" "Ottimo!"
E' facile sconfiggerti Azimuth, non sai quello che dici ;)


 E' facile sconfiggerti Azimuth, non sai quello che dici ;)
Perche' dovresti sconfiggermi???
Ce l'hai con me personalmente o in quanto qualcuno che manifesta la tua
incompentenza?
Ciao!
*** Azimuth ***

 incompentenza?
ROOOOOOOOOOOOOOOOOTFL!!!!!!!!
-- 
Luc.

 incompentenza?
ROTFL..
Tu non manifesti assolutamente *NULLA*, tanto e' vero che le stupidaggini
che affermi nei tuoi messaggi ti si stanno rivoltando contro (bimbo,
guardati intorno). Sei davvero convinto di riuscire a trovare incompetenza
negli altri, e' questa la cosa peggiore. Dalle idee confuse che hai sui
concetti *base* della programmazione, direi che non puoi insegnare nulla a
nessuno.


 nessuno.
Bel maestro che ci siamo trovati. <g>
*** Azimuth ***

 Nonostante le tue affermazioni siano ridicole ...
E' classico che si arrivi al punto in cui una persona reputi ridicole le
affermazioni che rovesciano del tutto le sue teorie. Io, per tua
informazione, programmo per lavoro e i miei clienti sono *oltremodo*
soddisfatti, il che e' indice del fatto che quanto affermo, applicato alla
realta', da dei risultati positivi (ti ho dimostrato che quanto affermi tu,
se per disgrazia venisse applicato alla realta', produrrebbe dei risultati
tragici). Non pretendo che tu, in questo contesto preciso, mi dia ragione,
capisco bene che ti rode il fatto che qualcuno sottolinei le tue
stupidaggini. D'altronde, da come stanno andando le cose nel thread, credo
proprio che faresti miglior figura a ritirarti in silenzio nei tuoi giochini
da revisore.



Niente affatto, quanto affermi e' una colossale *baggianata*.
</CITE>
<CITE Message-Id: 
80Z105Z34Z80Y1...@usenet.libero.it
 >
Stai tirando fuori degli argomenti del tutto insensati.
[...]
Dicendo questo, puoi solo stimolare delle grasse risate.
Per cortesia, discuti di argomenti piu' seri.
[...]
Capisco perfettamente che non hai argomenti, stai tirando fuori discorsi del
tutto privi di contenuto.
</CITE>
<CITE Message-Id: 
80Z105Z34Z80Y1...@usenet.libero.it
 >
Ennesima cazzata.
[...]
</CITE>
Basta, senno' ammorbo il NG.

 collega a cui ho visto il manuale aperto...
Lo criticavi senza neppure sapere che lo usavate?!  Grande, sei proprio
un grande... la comicita` italiana (magari involontaria) resta ai
vertici mondiali...
Quindi siete inesorabilmente destinati al fallimento causa il terribile
flagello dei virus mangiaspazi, vero?
Alex

 flagello dei virus mangiaspazi, vero?
Ti perdono perchè non sai quel che dici...
-- 
Luc.

 offesi da persone incompetenti[1].
"Hai diritto a rimanere in silenzio. Tutto quello che dirai potrà 
essere usato contro di te in tribunale. Rinunci a questo diritto?"
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 tua...
Azimuth, se giochi all'"io non sono X! tu sei X!", allora sì che 
dubitiamo della tua età, e a ragione
Non ho seguito molto la discussione, ma mi sembra di capire che Python 
tu non sai neanche com'è fatto (nemmeno io, ma almeno non ne parlo), e 
che lo giudichi dalla sintassi (malissimo, i linguaggi vanno giudicati 
dalla *semantica*, cioè se e come i problemi vengono risolti, non se si 
usano {}, begin/end o il rientro delle righe per delimitare i blocchi)


Non capisco, e comunque non critico python, ma il suo forced-indent.
ma che problemi ti causa? Io la trovo una delle cose più azzeccate.
Scrivi meno codice e più pulito
--
Rhymes (
rhymes_...@myself.com
)
http://www26.brinkster.com/rhymes
http://bw-crema.blogspot.com

Python è molto potente e consente di realizzare molti tipi di applicazione
con una semplicità sconosciuta a qualsiasi altro linguaggio , a parte forse
il Visual Basic.
Se poi devi creare codice molto efficiente e compatto è ovvio che il C e e
la sua evoluzione C++ siano migliori , ma i tempi di sviluppo necessari per
creare un applicazione in c/c++ a mio parere sono nettamente superiori.
Java non mi piace , è troppo lento , con Python o PHP puoi fare tutto quello
che fai con java ma con una velocità di esecuzione del codice molto
superiore.
Questo è quello che pensio io , per esperienza diretta.
Bye

il Visual Basic.
ma sono l'unico sulla terra che con il VB non č mai riuscito a
combinare nulla? Ho provato ad usarlo dopo un anno di Delphi ma me ne
sono tornato indietro dopo 2 giorni


 superiore.
E se col Python volessi fare un'applicazione sotto windows che abbia un
menu' a finestre, delle dialog box e un po' di grafica tipo giochino dello
stile break out o pac man che librerie dovrei usare?
Facciamo finta che non ho Python sul mio pc, ne' interprete, ne' ide, nulla
insomma, cosa dovrei installarmi?
Maurus

 nulla insomma, cosa dovrei installarmi?
Secondo me puoi partire scaricando la distribuzione standard di Python
per Windows e usando IDLE come IDE (e` scritto in Python con Tkinter)
e Tkinter come GUI toolkit; oppure scaricando la distribuzione Activestate
per Windows (+ grossa e ricca) e usando PythonWin come IDE e sempre
Tkinter come GUI toolkit.  Hai tante altre scelte, ma queste secondo me
sono le piu` semplici.
Alex

: Non ho seguito molto la discussione, ma mi sembra di capire che Python 
: tu non sai neanche com'è fatto (nemmeno io, ma almeno non ne parlo), e 
: che lo giudichi dalla sintassi (malissimo, i linguaggi vanno giudicati 
: dalla *semantica*, cioè se e come i problemi vengono risolti, non se si 
: usano {}, begin/end o il rientro delle righe per delimitare i blocchi)
Scusate se mi inserisco nella questione.
Ma non potrebbe essere che la qualità di un linguaggio stia in una sorta 
di via di mezzo, ragione per cui ENTRAMBI abbiate ragione?
Magari azimut avrà le sue idee riguardo all'indentazione (per carità, 
anche io ho le mie fisime a riguardo) pero' anche Maya non è in errore.
D'altra parte, neache io conosco tanto Python, e l'unica cosa che so è che 
si sta affermando come a suo tempo si affermò il perl per determinate aree 
informatiche. So solo che adesso debbo specializzarmi in un linguaggio 
(perché, pur invidiano Alex, io non posso imparare ad utilizzare tutti i 
linguaggi) e credo che non sarà il Python perché mi riesce difficile 
credere che il run-time che mette a disposizione abbia le stesse 
caratteristiche su tutte le piattaforme sulle quali lavorerò.
Spero comunque di non aver contribuito ad infuocare gli animi!
Fed.

caratteristiche su tutte le piattaforme sulle quali lavorerò.
Cosa intendi?
-- 
Marco Barisione (ICQ 84277092)

 caratteristiche su tutte le piattaforme sulle quali lavorerò.
Se il tuo problema principale e` la portabilita`, e` difficile che tu possa
fare una scelta migliore di Python.  In particolare, dovunque possa
girare il normale Java puo` girare il Python (nella versione Jython) con
le stesse librerie e le identiche caratteristiche di esecuzione, visto che
nella versione Jython usi la stessa JVM che useresti con Java.  Inoltre,
con Python puoi girare (sia pure con limitazioni) anche dove Java mi
pare abbia dei problemi (limitazioni piu` severe, o assenza? non so,
non sono + aggiornato!), come, che so, piattaforme Palm e Zaurus.
Per certi versi il linguaggio Tcl e` ancora piu` portatile; purtroppo e`
troppo limitato per farne l'_unico_ linguaggio da usare (non credo che
UN solo linguaggio possa mai bastare al professionista per il 100%
delle sue esigenze: ma se Python arriva al 90% o piu', Tcl a mio
parere si ferma molto prima -- e ha comunque vari problemi, a
mio vedere, anche per gli usi che almeno copre).
Alex

:: e credo che non sarà il Python perché mi riesce difficile 
:: credere che il run-time che mette a disposizione abbia le stesse 
:: caratteristiche su tutte le piattaforme sulle quali lavorerò.
: 
: Cosa intendi?
:
Ad esempio, nel mio lavoro ho bisogno che molti dei miei algoritmi vengano 
eseguiti in un "quanto di tempo" deterministicamente definito. In altre 
parole, ho bisogno di un tempo di esecuzione deterministico. Questo mi è 
possibile se ho garanzie rispetto ai tempi di esecuzione (ovvero se le mie 
routine vengono eseguite in tempi prefissati). Questo fin'ora l'ho trovato 
possibile solo con linguaggi dove era possibile avere una specifica 
dettagliata del tempo di esecuzione di ogni singolo statement o chiamata, 
oppure, in alternativa, dove le misure mi garantissero una soglia 
superiore, ovvero che la loro esecuzione non fosse mai superiore a quella 
durata. 
Ho visto che il C ed il C++ mi garantiscono questo, mentre Python non può 
per la sua natura interpretata. Anche Eiffel credo me lo garantisca, però 
non conoscendolo non mi pronuncio.
Poi ho visto che Python soffre di un altro problema (che riguarda la 
sua natura sintattica) quasi opposto a quello del C++ per la parte di 
programmazione generica. Ovvero è *troppo* flessibile per essere 
utilizzato in applicazioni estese.
Spiego anche se mi scuso in anticipo se non potrò essere preciso, dato 
che non sono molto addentro la terminologia del Python.
La mancanza di tipizzazione del Python significa che è fin troppo facile 
che ci si trovi in situazioni dove viene fatto riferimento ad un oggetto 
il cui tipo non è esattamente quello che ci si aspetta. IL fatto che il 
Python utilizzi una tecnologia di dispatching dei metodi veramente "a run 
time" può determinare un fallimento che non accade proprio nel punto dove 
vi è il problema ma magari più in là del punto nel quale è stato 
"rotto" il grafo delle derivazioni.
IL fatto che manchi la tipizzazione si associa poi alla maniera non 
dichiarativa con la quale le variabili di istanza vengono utilizzate, 
ovvero questo significa che qualsiasi errore di battitura può diventare 
mortale. Un esempio che mi viene in mente, mutuato da un esempio reale che 
mi è capitato sotto mano, è ad esempio il seguente: "campo.colore = Rosso" 
funzionerà bene anche se fino a quel momento avevo scritto "campo.colori"!
Ovviamente non credo che questi esempi possano minare la convenienza della 
sintassi del Python, d'altra parte può essere difficile garantire la 
qualità in sistemi medio-grandi.
Per un linguaggio o un ambiente di sviluppo, per essere utile seriamente 
per applicazioni di grande dimensione, è necessario trovare un approccio 
di analisi anticipata che permetta di comprendere esattamente il punto 
dove il codice fallisce. Un esempio che ho trovato molto interessante è il 
linguaggio Objective-C e Java, che in generale rispondono bene a questo 
requisito, anche se non sono real-time, purtroppo.
Entrambi i linguaggi sono dichiarativi per natura, e può essere noioso a 
volte, ma sicuramente elimina una serie di problemi come i nomi di 
variabile scritti male e problemi relativi a oggetti composti, che credo 
siano problemi comuni in applicazioni Python di grande dimensione.
Fed.

:: linguaggi) e credo che non sarà il Python perché mi riesce difficile
:: credere che il run-time che mette a disposizione abbia le stesse
:: caratteristiche su tutte le piattaforme sulle quali lavorerò.
: Se il tuo problema principale e` la portabilita`, e` difficile che tu 
: possa fare una scelta migliore di Python. 
Ecco, su questo volevo appunto porti una domanda: ma il C non è il 
linguaggio più portabile in assoluto? Voglio dire: fin'ora mi è capitato 
di avere tra le mani tanto hardware differente (motherboard custom con 
sopra processori 68000, processori strongARM della Intel su 
portatili/palmari industriali, PC assemblati Intel PIII, ...) e tanti 
sistemi operativi differenti (dal PDOS per MC68000 ai vari dialetti UNIX 
fino ad arrivare ai sistemi Microsoft Embedded e XP). In tutti il 
fornitore dava un ambiente di sviluppo con il compilatore C, che mi ha 
aiutato a sviluppare applicativi anche di una certa complessità, ma che 
sono riuscito a portare da un ambiente all'altro. Secondo te, con il 
Python potrò trovare sempre un ambiente di sviluppo su ognuno di questi 
ambienti?
: In particolare, dovunque possa
: girare il normale Java puo` girare il Python (nella versione Jython) 
: con le stesse librerie e le identiche caratteristiche di esecuzione, 
: visto che nella versione Jython usi la stessa JVM che useresti con Java.
Interessante, ma che differenze vi sono? E le performance?
: Inoltre,
: con Python puoi girare (sia pure con limitazioni) anche dove Java mi
: pare abbia dei problemi (limitazioni piu` severe, o assenza? non so,
: non sono + aggiornato!), come, che so, piattaforme Palm e Zaurus.
Che tipo di limitazioni? Voglio dire: con gli attuali ambienti, l'unica 
limitazione è sulla quantità di memoria disponibile.
: Per certi versi il linguaggio Tcl e` ancora piu` portatile; purtroppo e`
Mi dispiace, ma non lo conosco proprio!
Fed.

 essere usato contro di te in tribunale. Rinunci a questo diritto?"
Lo stesso diritto che hai tu, Maya.
Con la differenza che a te in tribunale non ti si puo' portare perche' sei
ancora minorenne...
*** Azimuth ***

 Mi dispiace, ma non lo conosco proprio!
Non e` il senso della parola portabilita` che tu stavi usando,
comunque.  E` piu` che altro una questione dell'ottima scalabilita`
di prestazioni che puoi avere con architetture asincrone basate
sugli eventi: per Tcl e` il principale modus operandi, mentre
Java e Python tendono (sulla base delle sole librerie standard)
a operare per thread, il che almeno su di una macchina con un
singolo processore non e` altrettanto performante/scalabile.
Python offre anche moduli asincroni nella libreria standard
(asyncore/asynchat), ma in pratica sei limitato all'uso con le
socket (su Unix/Linux/BSD anche altri file, ma non su Windows).
Ma il framework "Twisted" offre il modo di lavorare in paradigma
asincrono con loop di eventi specifico per le varie piattaforme,
e a mio parere scavalca persino le capacita` del loop degli eventi
di Tcl/Tk (ad esempio, Twisted offre implementazioni di "Reactor"
[astrazione dell'event loop come design pattern] ottimizzate per
Windows, con I/O asincrono e messaggi ecc; per Qt, con gli eventi
delle GUI integrati con gli altri in modo cross-platform; e cosi`
via, nonche` implementazioni dei piu` vari protocolli che sono
gia` praticamente pronte e puoi eventualmente personalizzare con
i normali, potenti meccanismi dell'OO -- eredita` e override --
offrendo a mio parere una soluzione complessiva _superba_).
Alex

 siano problemi comuni in applicazioni Python di grande dimensione.
Sbagli: in concreto, in pratica, non lo sono affatto.
Alex

perche' sei ancora minorenne...
da quanto ne so io Maya frequenta l'università e quindi le cose sono
due: 
1 - o Maya è una bimba prodigio e quindi fa l'università quando
dovrebbe essere al liceo, ma non credo :)
2 - oppure Maya è maggiorenne


 2 - oppure Maya è maggiorenne
Ce n'e' una terza: ce la portano i genitori per non lasciarla sola a casa.
*** Azimuth ***

Ciao Alex! Ho visto che mi hai risposto un bel po' di tempo fa, purtroppo 
leggo i messaggi solo la sera quando ritorno a casa dal lavoro! Avrei 
delle domande da farti, ma andiamo ad incominciare...
:: Ecco, su questo volevo appunto porti una domanda: ma il C non è il
:: linguaggio più portabile in assoluto? Voglio dire: fin'ora mi è 
:: capitato
: In termini di puro linguaggio, e` una bella gara fra C, Java, e
: Python.  Java e` controllato piu` strettamente, per cui differenze
: fra due implementazioni correnti sono meno probabili; 
Ma anche il C è controllato, a quanto ne so (ANSI?). Voglio dire, magari 
domani si alzano e cambiano tutto, ma almeno lo standard è super partes... 
o no?
: e Java
: nasconde quasi interamente le differenze relative all'hardware,
: poiche` gira su di una macchina virtuale rigorosamente specificata.
Uhmmm... dunque, non capisco esattamente la portata di questa cosa, ma 
posso immaginare che se avessi un processore a 64 bit potrei non riuscire 
a sfruttarlo a pieno con Java... o con Python...?
: Ad esempio, con Java conosci ESATTAMENTE ogni dettaglio delle
: caratteristiche della rappresentazione floating-point e del
: comportamento deiie varie operazioni FP:
Il C non supporta lo standard IEEE?
: decenti anche su HW strano -- ma scrivere applicazioni numeriche
: sofisticate CON le indispensabili caratteristiche di convergenza
: ecc e` una causa persa se non puoi contare su implementazioni
: assai piu` ricche e precise di quanto lo standard C non preveda.
Scusa, ma cosa intendi con "applicazioni numeriche"?
: Python e` in gara perche` puo` vivere in entrambi i mondi.  CPython,
: ovvero "Classic Python", si appoggia sul C e ne condivide le tipiche
: caratteristiche di "portabilita` attraverso la lassita`" -- ad
Cos'è esattamente il CPython?
:: sono riuscito a portare da un ambiente all'altro. Secondo te, con il
:: Python potrò trovare sempre un ambiente di sviluppo su ognuno di questi
:: ambienti?
: Non hai necessariamente bisogno di un ambiente di sviluppo: puoi
: anche trasferire direttamente il codice compilato ed eseguire quello.
Intendevo un ambiente run-time per ogni piattaforma con la quale 
lavorerò.
: Un ambiente 'hosted' e` uno in cui il tuo programma puo` contare su
: un certo insieme di funzionalita` di supporto da parte di un sistema
: operativo o di un qualche suo equivalente, come ad esempio l'esistenza
: di "file" e il concetto di "allocare memoria".  Un ambiente embedded
: non ti offre questo supporto: il tuo programma deve totalmente
: arrangiarsi, praticamente deve fare da sistema operativo di se stesso.
Beh, a dire il vero fin'ora ho scritto molte linee di codice C su diverse 
piattaforme, ma nessuna mi ha mai esposto qualcosa di più specifico di un 
malloc o di un fopen... è anche vero che non tutti i sistemi avevano un 
ambiente IDE, però me la sono sempre cavata con #define vari.
: risulta allora non soddisfatta.  (C'e` un parallelo sulla gestione
: dei dischi e altre memorie di massa: la maggior parte dei linguaggi
: o loro librerie standard prevedono l'esistenza di un "file system"
: gestito da "qualcun altro" -- se non c'e`, le normali librerie di
: I/O, come ad esempio la stdio del C, non sono applicabili, e devi
: occuparti invece nel "programma applicativo" stesso di gestire tu
: stesso i blocchi di disco, o le tracce, ecc ecc).
Per esempio, tutti gli ambienti con i quali fin'ora ho lavorato esponevano 
qualcosa di riconducibile allo standard input/output o ad un filesystem.
: Se la tua attivita` di sviluppo si impernia su sistemi "embedded"
: ("free-standing") per cui non sono disponibili gli elementi di
: supporto fondamentale, ti trovi in un certo senso a sviluppare
: sempre dei "sistemi operativi" o simili, non dei "programmi
: applicativi" stricto sensu.
Beh, mica vero. Ad esempio, è possibile che debba sviluppare presto sotto 
Windows CE (o Pocket PC 2002? Bah!), dove esiste il compilatore C/C++ 
(Embedded Visual C) ma il Python mi pare arrancare.
: Vantaggio sempre presente: la produttivita` di implementazione
: e manutenzione usando un linguaggio di livello superiore per
: lo "strato applicativo" migliora rispetto a quella ottenibile
: usando linguaggi di livello inferiore.  Java puo` offrire un
: vantaggio di 2-3 volte sul C per questa parte, Python di 5-10
: volte.
Tu parli di un "miglioramento di produttività": quali sono i tuoi 
parametri a riguardo? Per me è più produttivo scrivere 10 righe di codice 
testate ed efficienti rispetto a 10 righe di codice testate ma 
inefficienti...
: dell'HW a tua disposizione: se devi sfruttare al massimo ogni
: ciclo di macchina per essere competitivo, la considerazione e`
: importantissima, mentre se la potenza dell'HW che usi e` assai
: confortevole per le tue esigenze applicative, e` minore.
Diciamo che credo fermamente nel detto secondo cui "le macchine veloci 
premiano gli algoritmi intelligenti".
: license dei sorgenti di una JVM) e anche costi monetari di
: licenza.  La VM di Python e` molto facile da portare, e non ho
: mai visto nessun caso in cui ci fosse da pagare una licenza
: per averne il porting (certo non i sorgenti, sono Open Source).
OK, pero'... non credo proprio che un peso come Python possa essere 
portato comunque dappertutto (da qui il mio dubbio)...
: fatto da altri delle VM di classic Python, O qualsiasi porting
: commerciale (eventualmente pagando) della JVM standard; hai
: dunque piu` scelta;
L'unica cosa che non ho afferrato: ma JPython è interpretato SOPRA la JVM? 
Oppure è bytecode Java?
: (tipicamente, visto gli anni, sistemi a 8 bit con poche decine
: di K di RAM -- in realta` non d'interesse per le applicazioni
: [CAD e contorno] dell'azienda, ma, supponiamo), allora avrei
: dovuto fare delle scelte tecniche diverse (e piu` simili a
: quelle che feci nella realta`).
Diciamo, allora, che Python non è la scelta sicuramente migliore da fare 
in un ambiente con performances stringenti...?
: accettando questa valutazione, mi aspetterei di avere prestazioni
: eccellenti con Jython + questi ambienti, e solo buone con Python
: classico, Apache, e un qualche RDBMS pur sempre buono ma non ai
: livelli di "tuning" e scalabilita` di una grossa e perfetta
: istallazione Oracle -- tipo ad esempio PostgreSQL.
Oddio, Oracle mi sembra tutto fuorchè performante (ma è solo 
un'impressione, spero!).
:: Che tipo di limitazioni? Voglio dire: con gli attuali ambienti, l'unica
:: limitazione è sulla quantità di memoria disponibile.
: La quantita` di memoria, di lavoro e di massa, e` la principale
: limitazione, ma non direi l'unica; ad esempio, il floating point
: mi pare che possa essere un problema (non saranno sparite TUTTE
: le piattaforme non a pieno standard IEEE, temo...?-).
A quanto mi risulta, la IEEE viene gestita dal run-time del C...?
Per il resto del messaggio, ti ringrazio dei suggerimenti!!
Fed.

:: Ho visto che il C ed il C++ mi garantiscono questo, mentre Python non 
:: può per la sua natura interpretata. Anche Eiffel credo me lo 
:: garantisca, però
: Veramente la "natura interpretata" non ha nulla a che vedere con il
: tuo problema,
Beh, in una certa misura sì. Mi spiego: quando ho a che fare con un 
interprete, posso immaginarmi che il tempo di esecuzione di una singola 
istruzione non sia necessariamente costante, dato che esso non viene 
tradotto in un insieme di istruzioni macchina (CPU) bensì passa attraverso 
analizzatori lessicali e parser di varia natura e complessità, che non 
necessariamente eseguono il loro compito in tempo costante. Alex dimmi che 
non ho preso una topica!
: e C e C++ non garantiscono nulla in questi termini --
Beh, per esempio l'inlining mi garantisce che non viene chiamata una 
funzione con una CALL, ad esempio, e così risparmi diverso tempo 
inutilmente speso in smanettamenti dello stack...
: gli standard del linguaggio C++ offrono garanzie solo sul comportamento
: "big-O" delle operazioni della libreria standard (non tutte), e non
: e` quello che ti serve (nulla di rigorosamente deterministico).
Pero' posso valutare il codice assembly prodotto per avere un'idea del 
tempo di esecuzione.
: 
: Ad esempio, l'istruzione C o C++
:         i = j;
: potrebbe richiedere operazioni di memoria virtuale comprendenti
: sostanziali quantita` di I/O su disco, e addio ai "tempi prefissati".
: Qualsiasi _linguaggio_ in gioco non puo` far nulla per evitarlo.
Vero. Però ad esempio
	i = j;
viene tradotto generalmente in 2-3 istruzioni macchina (oppure zero se il 
compilatore è intelligente e riesce a fare aliasing). L'esecuzione di 
queste istruzioni con qualsiasi processore è ben veloce che interpretare 
la stessa cosa più volte. Almeno questo è quello che mi è parso fin'ora 
nella mia pur limitata esperienza.
: Presumibilmente tu operi in ambienti senza alcun multi-tasking
: (almeno non pre-emptive) e neppure memoria virtuale -- in pratica
: dunque senza OS o con un OS specializzato per il real-time.  Ancora
: si possono avere problemi relativi alle cache, e qui la questione
: del determinismo dipende piu` che altro dall'hardware che usi.
Guarda, fin'ora nessun mio algoritmo è morto per un cache missing, e 
d'altra parte ne ho molti di più al crescere della dimensione 
dell'eseguibile... per esempio, quant'è "in kylobytes attivi" 
l'occupazione di Python? Hai qualche misura a riguardo o qualche pagina 
web da leggere?
: Una volta fissati tutti questi parametri non c'e` ragione per
: cui un linguaggio interpretato debba avere prestazioni meno
: deterministiche di uno il cui compilatore genera invece
: linguaggio macchina.
A me è successo di vedere alcune implementazioni di interpreti fallire 
miseramente questo obiettivo semplicemente perché avevano sbagliato nel 
mettere in ordine di esame le istruzioni più usate da quelle meno usate...
: vincoli di real-time stretto, l'alternativa ai linguaggi di
: basso livello come C e` offerta piuttosto da altri linguaggi
: progettati appositamente per simili ambienti (e.g. Erlang,
: ma specificamente nel settore telecom, non so per altri).
Ho sentito parlare di Erlang, ed un mio amico mi ha pure cercato di 
convincere ad usarlo. Però ho notato che l'Erlang è un linguaggio 
funzionale... non mi ha saputo spiegare come avviene la traduzione in 
linguaggio assembly...
: Su questo, sbagli.  I linguaggi a tipizzazione dinamica (come
: Python, ma anche Smalltalk, vari Lisp, Erlang, ecc ecc) hanno
: *ampiamente* dimostrato di essere perfettamente adatti all'uso
: in applicazioni estese: i timori da te (e altri) espressi non 
: trovano riscontro nella prassi.
Scusa Alex, ma io ho bisogno di qualcosina di più per convincere i miei 
superiori di una scelta del genere. Dire che è la "prassi" è come dire che 
è "di moda". eheheh...
: L'unica soluzione generale e` il testing: che non puo` essere
: esaustivo, ma copre comunque una frazione molto piu` significativa
: dei tipici casi d'errore rispetto a quelli che puo` coprire il
: "controllo dei tipi" (anche in un linguaggio con un BUON sistema
: di tipi, come Haskell o ML -- lasciamo perdere i sistemi di tipi
: "offerti" da C, C++, o anche Java, che e` meglio:-).
A me sembra, però, che il C ed il C++ siano più rigorosi e più validi per 
un testing approfondito, ma magari non ho abbastanza conoscenze a 
riguardo.
: Un insieme di test ben lungi dall'essere considerato sufficientemente
: ricco e completo copre (ampiamente!) tutti i modesti controlli che
: un compilatore per C, C++ o Java puo` compiere sulla base della
: tipizzazione compile-time, e piu` ancora.  Se la tipizzazione
: compile-time (soprattutto in linguaggi che la traducono in obbligo
: di dichiarazione, invece di affidarsi all'inferenza dei tipi come
: Haskell o ML) riduce la produttivita` su grandi applicazioni di
: un tempo sufficiente per migliorare la suite di test, e questo e`
: quello che le misurazioni confermano, allora l'affidabilita`
: complessiva della grande applicazione sara` maggiore se essa viene
: sviluppata in un linguaggio a tipizazione rigorosa ma dinamica.
A me sembra un discorso un po' pericoloso... è come dire che se la catena 
di montaggio produce il doppio dei pezzi nella stessa unità di 
tempo saltando i controlli ad ogni step, il tempo risparmiato può essere 
impiegato per fare i test finali...
: Il fallimento viene diagnosticato esattamente quando le ipotesi
: di comportamento falliscono.  La situazione e` MOLTO migliore di
: quella che hai ad esempio in C relativamente ai puntatori.  Se
In effetti con il C ed il C++ + più difficile tenere sotto controllo i 
puntatori, però è anche vero che posso "isolare" il materiale pericoloso, 
e racchiudere le allocazioni e le deallocazioni tutte da una parte, 
isolando i punti di leaking.
Per il resto direi che sono d'accordo con te.
Fed.

A quanto mi risulta, la IEEE viene gestita dal run-time del C...?
che significa la tua frase? IEEE è un'associazione 


Azimuth ha scritto:

o una quarta: Azimuth è un cretino con un grave caso di invidia penis


 o una quarta: Azimuth è un cretino con un grave caso di invidia penis
A questo punto inizio a non capirci più niente.
Ma tu non eri una bambina/ragazza/donna/vecchia? (non vorrei sbagliare
ulteriormente!)
Kiuhnm

 beh è un pò come la storiellina di Java nelle lavatrici :)
... e infatti Java non c'e' nelle lavatrici![1]
Ciao!
*** Azimuth ***
[1] Almeno, non c'e' nella mia. :)

 ulteriormente!)
Guarda, su alcune questioni e' umano avere dubbi, ma non su questa:
sicuramente ci troviamo di fronte ad una persona che ha avuto una infanzia
difficile e si rifa' sull'informatica e sulle persone che affollano i
newsgroup.
Ci vuole solo un po' di tolleranza, tutto qua.
Ciao.
*** Azimuth ***

 wxPython (riveste wxWindows).  Poi ce ne sono un'altra dozzina.
Ciao Alex,
mi permetto di postare un messaggio in questo thread visto che si sta
parlando di scelta del GUI toolkit da usare con Python, con l'intento di
andare poi ad approfondire eventualmente il discorso sul ng apposito (i.e.
it.comp.lang).
Quali sono le maggiori differenze tra i vari toolkit?
In che cosa PyQT risulta essere più professionale?
Forse nel tipo e nel numero dei 'controlli' visuali messi a disposizione
(leggendo un po' di documentazione Tkinter sembra mancare di alcuni
controlli tipo le visualizzazioni ad albero e pare sia l'unica che sotto
Windows non assuma l'aspetto tipico di una applicazione MS,..., cosa,
secondo me, non molto importante).
Al momento (e da non molto) utilizzo Python con grandissima soddisfazione,
anche se non ho ancora cominciato a sviluppare applicazioni con GUI.
Ora mi trovo a voler fare in modo tale da sfruttare questo linguaggio e le
sue peculiarità (quali ad esempio la possibilità di muovere il tutto sotto
Linux, compreso lo strato della GUI) al fine di sostituire i
linguaggi/ambienti che uso attualmente (VB, VC++,Delphi) e devo scegliere il
framework adatto per la costruzione delle GUI.
Mi piacerebbe avere un tuo personale parere al proposito.
Ti ringrazio anticipatamente per il supporto e mi complimento per i tuoi
bellissimi post su Python.
Tempo fa anche io scoprii l'esistenza di Python e fui spinto ad utilizzarlo
proprio a 'causa' di un tuo post su di un ng.
Pian pianino ho cominciato a metterci le mani e giorno dopo giorno mi trovo
a volerlo usare sempre di più per lo sviluppo delle applicazioni più
disparate e la cosa bella è che...effettivamente...pare non si abbiano
limiti grazie alle caratteristiche del linguaggio stesso (multipiattaforma,
oo, molto semplice ed immediato, estremamente produttivo), al supporto delle
comunità e dei singoli appassionati, alla disponibilità di una marea di
estensioni.
Non nascondo che all'inizio avevo cominciato ad impiegarlo per il test di
alcuni algoritmi e per lo sviluppo molto veloce di 'prototipi' che venivano
riscritti successivamente con altri linguaggi.
Grazie ancora e buon lavoro!
dix

 wxPython (riveste wxWindows).  Poi ce ne sono un'altra dozzina.
Ciao Alex,


 Grazie ancora e buon lavoro!
Prego ancora, e altrettanto!
Alex

 che significa la tua frase? IEEE è un'associazione
Presumibilmente intende lo standard originato dall'IEEE sul
floating point.  Puo` essere emulato in software dal runtime,
ma solo a prezzi MOSTRUOSI di prestazioni: in pratica se non
e` nell'hardware e` meglio dargliela su e accontentarsi di
un floating point non-standard.
Alex

bit, come fai a sfruttare i 64 bit?
non mi pronuncio perchè non saprei. Non ho mai scritto ne studiato a
fondo l'architettura di una VM


palmari molto migliori!) 
tutti quelli equipaggiati con PalmOS :P ?


Quali sono le maggiori differenze tra i vari toolkit?
http://phaseit.net/claird/comp.lang.python/python_GUI.html
http://sensei.co.il/python/ui.html
http://phil.freehackers.org/kde/cmp-toolkits.html


 isolando i punti di leaking.
Non stiamo parlando di leaking ma di sporcamento: una funzione
che si aspetta di ricevere un puntatore ad un'area che in
queste circostanze dovrebbe essere di 24 byte riceve invece
un puntatore ad un'area di soli 20 byte, ad esempio.  Scrive
pero` tranquillamente tutti i 24 byte, cosi` oltre all'area
che le era effettivamente stata passata, scrive spazzatura
su di un int che, poveretto, si trovava immediatamente dopo
quest'area (ad esempio in stack, o nella zona delle variabili
statiche).  Molto tempo dopo qualcuno usa quell'int, e ...
(qui cala, pietoso, il sipario).
Non che siano meccanismi INGESTIBILI: l'ingegno umano ha ben
pochi limiti; ma che un gruppo di sviluppo abituato a dover
lottare con questi problemi consideri ALTRI linguaggi (che
non li hanno) "meno rigorosi" (?!) sfiora i limiti del credibile:-)
Fuori di scherzo e per non lasciar dubbi, credo pienamente alla
tua buona fede, ma mi pare che ci siano strane falle nel tuo
ragionamento.  Se il rigore ecc ecc sono DAVVERO cosi` cruciali
per i vostri sviluppi, perche` non usate ADA o Eiffel...?
Alex

comprarne copia cartacea).  
ma sono l'unico che non è mai riuscito a trovare una versione
scaricabile e non per forza consultabile dal web?


 Per il resto del messaggio, ti ringrazio dei suggerimenti!!
Prego!
Alex

L'uso di malloc
ho appena letto su 
programmazione.it
 che nella nuova GNU C library 2.3
hanno riscritto completamente la malloc


 sbagliare ulteriormente!)
č un caso MOLTO grave


Grazie mille per la competenza e la disponibilità!
Ciao
dix

 
http://phil.freehackers.org/kde/cmp-toolkits.html
Questi link mi sono davvero utili...ora li leggo per benino!
Grazie!
Ciao
dix