Re: [Python] cambio al vertice
On Wed, 1 Apr 2009 11:31:18 +0200, Masci wrote: > Le motivazioni non fanno una grinza... > > http://www.python.org/dev/peps/pep-0401/ Notizione ogg! Fa il paio con questa: http://www.postgresql.org/community/weeklynews/pwn20090401 -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] cambio al vertice
Masci spiffera, alle Wednesday 01 April 2009 circa: > Le motivazioni non fanno una grinza... > http://www.python.org/dev/peps/pep-0401/ ROTFL! -- -gaspa- --- https://launchpad.net/~gaspa - -- HomePage: iogaspa.altervista.org --- -Il lunedi'dell'arrampicatore: www.lunedi.org - ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] cambio al vertice
Le motivazioni non fanno una grinza... http://www.python.org/dev/peps/pep-0401/ Ciao Masci ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] costruzione GUI
Innanzitutto grazie per le spiegazioni! Da quanto hai scritto deduco che evidentemente mi hanno chiesto di sviluppare la GUI a "manina" (usando wxpython) perchè devo aggiungere al frame un canvas in cui inserire oggetti (immagini, testo) su cui realizzare a "manina" il drag and drop, lo zoom, applicare maniglie per ridimensionare gli oggetti, ecc. Tutto questo non si può fare con un GUI builder? Inoltre hai scritto che solo in fase di costruzione della GUI il dover leggere a runtime un file xml da interpretare per creare la GUI richiede un po' di tempo di esecuzione in più rispetto ad una generazione "diretta" da codice. Ma ciò non è necessario nel corso della successiva esecuzione, perchè? Forse perchè nella successiva esecuzione in entrambi i casi ho il bytecode? Perdonami ma sono all'inizio con python e GUI Dany Il giorno 28 marzo 2009 13.31, Massimo Masson ha scritto: > danielita ha scritto: > > Ok, è chiaro, > > ma questo significa anche che: > > realizzata la GUI con wxpython, quando l'utente finale utilizzerà la GUI > > sarà tutto più veloce??? > > [...] > > Secondo me, gli strumenti che usi per costruire la GUI non hanno > influenza alcuna sulla velocità di esecuzione (a parità di altre > condizioni), ma solamente sui tempi di scrittura del codice. > > Scrivere "a mano" è solo più tedioso che lasciarlo fare ad un programma > apposito (GUI builder). "A mano" potresti avere il vantaggio di maggiori > personalizzazioni ma, considerando che costriuire GUI è _molto_ > ripetitivo, secondo me è meglio lasciarlo fare ad un apposito designer > (sw). > > Iniziando ad usare un GUI builder ti accorgi subito che esso non fa > altro che "scrivere codice ripetitivo" al posto tuo, sulla base di > elementi che inserisci "visivamente" e parametrizzi. Molto comodo. > Ovviamente ciò non basterà per la tua applicazione, perché vorrai fare > altre cose (tipo richiamare metodi al verificarsi di eventi), ed a > questo punto i vari GUI Builder, con 3 o 4 tecniche diverse (ma sempre > stessa sostanza) ti consentiranno di aggiungere "tuo codice" al posto > giusto. Questo è già molto comodo, ma dopo un po' ti accorgerai che > rigenerare i files ogni volta diverrà scomodo, ed alle volte > "pericoloso" (quando dovrai sovrascrivere i files vecchi, e rischierai > di perdere pezzi di codice a causa di overwrite... a me è capitato...). > > A questo punto ci sono varie strade per evolvere, il mio primo passaggio > è stato quello di utilizzare il GUI builder per generare solo le classi > di descrizione della GUI, da cui derivare le mie classi che > aggiungessero solo i metodi necessari (le risposte agli eventi di cui > sopra). In tal modo, anche perdendo il sorgente generato dal GUI > builder, non ci sono particolari problemi, basta rigenerarlo. Più > sicuro, più elegante, più comodo... > > ...ma non è detto che nemmeno questo ti soddisfi pienamente. > Ci sono altre soluzioni più eleganti (ad esempio Glade per GTK, o xrc > per wxWidgets aka wxPython) che generano "al volo" (a runtime) la GUI > sulla base di un file di descrizione (normalmente in formato xml). In > questo scenario il GUI builder non genera più codice, ma il file xml. > > Questa forse è la differenza di velocità di esecuzione di cui parli, il > dover leggere a runtime un file xml da interpretare per creare la GUI > richiede un po' di tempo di esecuzione in più rispetto ad una > generazione "diretta" da codice. > Tieni però presente che ciò è necessario solo in fase di costruzione > della GUI, e non nel corso della successiva esecuzione (ci mette magari > qualche istante in più a "disegnarsi" all'inizio, ma poi la velocità di > esecuzione è la stessa con entrambe le tecniche). > > A questo punto sei tornata a scrivere "a mano" il codice, che però è di > pochissime righe, tipo: "crea questo dialog sulla base di questa > definizione trovata in questo file; visualizza" (ovvio che il > virgolettato non è pseudocodice... :) ). > > Hai a questo punto il vantaggio di poter controllare tutto nei dettagli, > mantenendo anche quello di "disegnare" esternamente la GUI. Hai codice > "pulito" (beh, dipende da come lo scrivi...) ma hai anche un ulteriore > vantaggio: se con un gui builder che produce "codice" sei legata a > _quel_ GUI builder e quel linguaggio, passando a files di descrizione > delle risorse puoi tranquillamente cambiare da un GUI builder > (programma) all'altro (beh, più o meno...) ed _eventualmente_ da un > linguaggio ad un altro (anche se, ovviamente, non si capisce perché > dovresti passare da Python ad un qualsiasi altro linguaggio... ;) ). > > Ad esempio, alla fine del "giro" descritto io personalmente apprezzo > Glade su GTK, e wxFormBuilder su wxWidgets/wxPython (oppure in > alternativa anche wxGlade). > > Svantaggi veri dei GUI builder? Se hai da disegnare interfacce che per > qualche motivo non riescono a gestire, o se devi usare widget non > standard, in alcuni casi può diventare più complesso, ma nella > stragrande maggioranza dei casi imho è
Re: [Python] costruzione GUI
Ciao Daniela ti do un parere perche' ho avuto lo stesso problema come con le wxPython anche in java con le swing l'approccio GuiBuilder e' ovviamente molto intuitivo e veloce ma se e' la tua prima esperienza con queste tecnologie ti consiglio di cominciare a manina prima di far fare i mestieri all' IDE RAD cosi' capirai piu' a fondo il contesto e sopratutto imparerai dai tuoi errori quando avrai masterizzato (to master) le wx potrai passare ad un gui builder comprendendo meglio quello che gli chiedi di fare al tuo posto e sapendo intervenire senza esitazione nel momento gisto e al posto giusto. questa la mia esperienza Il giorno 1 aprile 2009 13.16, danielita ha scritto: > Innanzitutto grazie per le spiegazioni! > > Da quanto hai scritto deduco che evidentemente mi hanno chiesto di > sviluppare la GUI a "manina" (usando wxpython) perchè devo aggiungere al > frame un canvas in cui inserire oggetti (immagini, testo) su cui realizzare > a "manina" il drag and drop, lo zoom, applicare maniglie per ridimensionare > gli oggetti, ecc. Tutto questo non si può fare con un GUI builder? > > Inoltre hai scritto che solo in fase di costruzione della GUI il dover > leggere a runtime un file xml da interpretare per creare la GUI richiede un > po' di tempo di esecuzione in più rispetto ad una generazione "diretta" da > codice. > Ma ciò non è necessario nel corso della successiva esecuzione, perchè? > Forse perchè nella successiva esecuzione in entrambi i casi ho il bytecode? > > Perdonami ma sono all'inizio con python e GUI > > > Dany > > Il giorno 28 marzo 2009 13.31, Massimo Masson ha > scritto: > > danielita ha scritto: >> > Ok, è chiaro, >> > ma questo significa anche che: >> > realizzata la GUI con wxpython, quando l'utente finale utilizzerà la GUI >> > sarà tutto più veloce??? >> >> [...] >> >> Secondo me, gli strumenti che usi per costruire la GUI non hanno >> influenza alcuna sulla velocità di esecuzione (a parità di altre >> condizioni), ma solamente sui tempi di scrittura del codice. >> >> Scrivere "a mano" è solo più tedioso che lasciarlo fare ad un programma >> apposito (GUI builder). "A mano" potresti avere il vantaggio di maggiori >> personalizzazioni ma, considerando che costriuire GUI è _molto_ >> ripetitivo, secondo me è meglio lasciarlo fare ad un apposito designer >> (sw). >> >> Iniziando ad usare un GUI builder ti accorgi subito che esso non fa >> altro che "scrivere codice ripetitivo" al posto tuo, sulla base di >> elementi che inserisci "visivamente" e parametrizzi. Molto comodo. >> Ovviamente ciò non basterà per la tua applicazione, perché vorrai fare >> altre cose (tipo richiamare metodi al verificarsi di eventi), ed a >> questo punto i vari GUI Builder, con 3 o 4 tecniche diverse (ma sempre >> stessa sostanza) ti consentiranno di aggiungere "tuo codice" al posto >> giusto. Questo è già molto comodo, ma dopo un po' ti accorgerai che >> rigenerare i files ogni volta diverrà scomodo, ed alle volte >> "pericoloso" (quando dovrai sovrascrivere i files vecchi, e rischierai >> di perdere pezzi di codice a causa di overwrite... a me è capitato...). >> >> A questo punto ci sono varie strade per evolvere, il mio primo passaggio >> è stato quello di utilizzare il GUI builder per generare solo le classi >> di descrizione della GUI, da cui derivare le mie classi che >> aggiungessero solo i metodi necessari (le risposte agli eventi di cui >> sopra). In tal modo, anche perdendo il sorgente generato dal GUI >> builder, non ci sono particolari problemi, basta rigenerarlo. Più >> sicuro, più elegante, più comodo... >> >> ...ma non è detto che nemmeno questo ti soddisfi pienamente. >> Ci sono altre soluzioni più eleganti (ad esempio Glade per GTK, o xrc >> per wxWidgets aka wxPython) che generano "al volo" (a runtime) la GUI >> sulla base di un file di descrizione (normalmente in formato xml). In >> questo scenario il GUI builder non genera più codice, ma il file xml. >> >> Questa forse è la differenza di velocità di esecuzione di cui parli, il >> dover leggere a runtime un file xml da interpretare per creare la GUI >> richiede un po' di tempo di esecuzione in più rispetto ad una >> generazione "diretta" da codice. >> Tieni però presente che ciò è necessario solo in fase di costruzione >> della GUI, e non nel corso della successiva esecuzione (ci mette magari >> qualche istante in più a "disegnarsi" all'inizio, ma poi la velocità di >> esecuzione è la stessa con entrambe le tecniche). >> >> A questo punto sei tornata a scrivere "a mano" il codice, che però è di >> pochissime righe, tipo: "crea questo dialog sulla base di questa >> definizione trovata in questo file; visualizza" (ovvio che il >> virgolettato non è pseudocodice... :) ). >> >> Hai a questo punto il vantaggio di poter controllare tutto nei dettagli, >> mantenendo anche quello di "disegnare" esternamente la GUI. Hai codice >> "pulito" (beh, dipende da come lo scrivi...) ma hai anche un ulteriore >> vantaggio: se con un gui builder che p
Re: [Python] costruzione GUI
concordo...io inizia al contrario e poi sono passato a farmi tutto a manina. Ora uso un approccio misto. -- Quiero ser el rayo de sol que cada día te despierta para hacerte respirar y vivir en me. "Favola -Moda". ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] cambio al vertice
Daniele Varrazzo ha scritto: > On Wed, 1 Apr 2009 11:31:18 +0200, Masci wrote: >> Le motivazioni non fanno una grinza... >> >> http://www.python.org/dev/peps/pep-0401/ > > Notizione ogg! Fa il paio con questa: > > http://www.postgresql.org/community/weeklynews/pwn20090401 Sapete in che data state scrivendo, vero? ^_^ max ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] costruzione GUI
danielita ha scritto: > Innanzitutto grazie per le spiegazioni! > > Da quanto hai scritto deduco che evidentemente mi hanno chiesto di > sviluppare la GUI a "manina" (usando wxpython) perchè devo aggiungere al ...scusa non ti sto seguendo molto... da quanto scrivo io "tu deduci" una cosa che "hanno chiesto a te" ??? Non mi quadra... > frame un canvas in cui inserire oggetti (immagini, testo) su cui > realizzare a "manina" il drag and drop, lo zoom, applicare maniglie per > ridimensionare gli oggetti, ecc. Tutto questo non si può fare con un GUI > builder? Beh, no... con il GUI builder costruisci i widget di interfaccia, uno dei quali sarà un canvas, all'interno del quale poi le cose le realizzerai programmandole tu... (il GUI builder "disegna" i componenti dell'interfaccia, e basta... il canvas è un widget, il gui builder si ferma li...). Peraltro, se le tue richieste riguardano oggetti (con maniglie, da ridimensionare, e via dicendo) da gestire via wxPython, ti suggerirei di guardare, nella demo standard, la sezione "OGL" (sotto miscellaneous mi pare...) > Inoltre hai scritto che solo in fase di costruzione della GUI il dover > leggere a runtime un file xml da interpretare per creare la GUI richiede > un po' di tempo di esecuzione in più rispetto ad una generazione > "diretta" da codice. > Ma ciò non è necessario nel corso della successiva esecuzione, perchè? > Forse perchè nella successiva esecuzione in entrambi i casi ho il bytecode? Probabilmente non sono stato chiaro, con "costruzione della gui" intendevo la creazione dei vari widget da parte del programma (in esecuzione), non il tempo di design da parte del programmatore... Il concetto è che nel caso si usi un file di risorse che descrive la GUI il programma, per disegnare la stessa, deve leggere un file di testo che descrive la GUI, e sulla base di quella descrizione generare i widget. Se il tutto è codificato (ovvero già scritto nel codice) in esecuzione si può procedere a generare i widgets senza leggere la descrizione dal file di testo. Questa è la differenza(1). Poi le GUI generate, a parità di widget usati, si comportano nello stesso identico modo. Ovviamente la lettura del file di configurazione verrà effettuata ad ogni esecuzione. HTH, max. (1) questa differenza di esecuzione è piccola con Python, ma può diventare più significativa con linguaggi compilati, tipo C++, che non devono interpretare il sorgente (o p.code). Peraltro, nei linguaggi compilati consente l'innegabile vantaggio di poter "rifare" la gui senza dover ricompilare il sorgente. In Python te ne accorgi "meno" perchè potresti facilmente modificare il codice, ma se fossi in ambienti dove il sorgente va "protetto" la strada dei files di risorse diventa estremamente importante. ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] costruzione GUI
On Wed, 1 Apr 2009 15:43:15 +0200, salvatore monaco wrote: > Ciao Daniela > ti do un parere perche' ho avuto lo stesso problema > come con le wxPython anche in java con le swing > > l'approccio GuiBuilder e' ovviamente molto intuitivo e veloce > ma se e' la tua prima esperienza con queste tecnologie ti consiglio di > cominciare a manina prima di far fare i mestieri all' IDE RAD > cosi' capirai piu' a fondo il contesto e sopratutto imparerai dai tuoi > errori > quando avrai masterizzato (to master) le wx potrai passare ad un gui > builder > comprendendo meglio quello che gli chiedi di fare al tuo posto e sapendo > intervenire senza esitazione nel momento gisto e al posto giusto. +1 Penso che i GUI builder siano strumenti che semplificano un lavoro tedioso, ma che sia fondamentale capire quello che fanno, perché non fanno altro che creare una descrizione di una sequenza di operazioni. Quando qualcosa comincia ad andare male è necessario avere un minimo di dimestichezza con le operazioni che si intendevano svolgere, altrimenti il debug diventa impossibile. Il fatto che non sia questo che ha insegnato il Visual Basic è un discorso diverso: quella è una scelta di design ormai considerata fondamentalmente sbagliata e di cui non è il caso ripercorrere gli errori. Tra l'altro, in WX (come in QT e immagino altrove) esistono i Sizer che consentono di non dover specificare in maniera assoluta il posizionamento dei widget, ma solo in maniera relativa, per cui descrivere a codice un'interfaccia non è un'operazione che richiede il disegno sulla carta millimetrata. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
