Re: [Python] IDE per Python

[Enrico Franchi]

On 28/mar/07, at 22:20, Paolo Amodio wrote:

Credo che ora andrò a scaricarmelo (anche se uso BBEdit con  
soddisfazione...)


Prova, leggi i consigli che ho dato anche a solimo (ovvero scaricati con
svn tutti i bundles e poi spendi un po' di tempo curiosando fra i menu).

Una cosa cui si fa presto l'abitudine è la selezione verticale (con  
eventuale sostituzione in gruppo).

Si attiva con option.


-enrico

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Pattern singleton e chiamata __call__

[efphe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lawrence Oluyede wrote:
>> Non abbiamo bisogno del singleton, ne del borg. Li abbiamo gia'.
> 
> Non che mi sia mai servito ma perché dovremmo evitare Borg?

La domanda dovrebbe essere esattamente invertita: perche' dovremmo
usarlo, invece di preferire le classi e gli static methods?

- --
efphe
Today is Boomtime, the 14th day of Discord in the YOLD 3173
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD4DBQFGCwQGi7obm7aBjHcRAhwGAJj/t32oecJOOMwntlYIqloHEioIAJsEkzKc
CHMU3X+ALVlQDm2+zx3eZg==
=y0RP
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Pattern singleton e chiamata __call__

[Alan Franzoni]

Il 29/03/07, efphe<[EMAIL PROTECTED]> ha scritto:

Non abbiamo bisogno del singleton, ne del borg. Li abbiamo gia'.

Usa le classi (senza istanziarle) e gli staticmethods.


Aggiungo un'altra possibilità (ma dipende dall'uso che uno deve
farne): usa un modulo, che importi ovunque serva.

--
Alan Franzoni <[EMAIL PROTECTED]>
-
GPG Key Fingerprint:
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Pattern singleton e chiamata __call__

[Lawrence Oluyede]

Non abbiamo bisogno del singleton, ne del borg. Li abbiamo gia'.


Non che mi sia mai servito ma perché dovremmo evitare Borg?



--
Lawrence, oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Pattern singleton e chiamata __call__

[efphe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sbaush wrote:
> Ciao a tutti. Sto sviluppando una applicazione Python e mi sono trovato a
> dover implementare il pattern Singleton, seguendo quanto descritto in [1].
> Ho trovato diverse soluzioni su internet già scritte quindi il mio lavoro si
> è trasformato nel dover scegliere quella che sembrava adattarsi meglio alla
> vera natura del problema ed alla più corretta implementazione della
> soluzione.

Il mio piu' caldo, personale consiglio e' quello di evitare
*assolutamente* questo design pattern in python. Produce del maligno
(problemi con ereditarieta' ed ereditarieta' multipla e codice
illeggibile, almeno).

Non abbiamo bisogno del singleton, ne del borg. Li abbiamo gia'.

Usa le classi (senza istanziarle) e gli staticmethods.

Esempio:

  ### BEGIN ###
  class A:

   bar= 1

   @staticmethod
   def foo():
print 'foo'

   @staticmethod
   def set_bar(value):
A.bar= value

   @staticmethod
   def get_bar():
return A.bar

  class B(A):
   pass

  A.get_bar()
  A.set_bar(11)
  b= B()
  c= B()
  b.get_bar()
  c.get_bar()
  b.set_bar(10)
  c.get_bar()
  ### END ###


Non istanziare A, usala direttamente.
Puoi invece instanziare tranquillamente delle sottoclassi di A.

In conclusione, il mio consiglio (da adattare piu' o meno alle tue
esigenze) e':

1- dichiara una classe e dotala di tutti gli statimethods di cui
necessiti.
2- quando una classe dovra' incarnare il tuo singleton, basta ereditare.


- --
efphe
Today is Boomtime, the 14th day of Discord in the YOLD 3173
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFGCv9Vi7obm7aBjHcRAjbNAJ4srvslbZw7qTXf5fPRWqQM0/sdOACcC1Py
QHRjh6apBi6TfEyJDqkW5F4=
=1PGi
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Pattern singleton e chiamata __call__

[Sbaush]

Ciao a tutti. Sto sviluppando una applicazione Python e mi sono trovato a
dover implementare il pattern Singleton, seguendo quanto descritto in [1].
Ho trovato diverse soluzioni su internet già scritte quindi il mio lavoro si
è trasformato nel dover scegliere quella che sembrava adattarsi meglio alla
vera natura del problema ed alla più corretta implementazione della
soluzione.
La mia scelta si è abbattuta sulla soluzione riportata nella mail,
perfettamente funzionante e secondo me ben implementata (trovata in un
commento di [2])
Ci sono però nel listato delle parti che non ho capito bene e che vorrei
portare all'attenzione della lista.

1) La classe TestSingletonHelper è una classe "interna" alla classe
TestSingleton, ed ha il metodo __call__
Questo serve per rendere di fatto privato l'__init__ della classe
TestSingleton, che così viene reso inaccessibile. Perchè si è reso
necessario l'uso di __call__? cosa realizza di preciso?
2) def __call__( self, *args, **kw ) : perchè a __call__ viene passato
*args, **kw ? Cosa sono? a cosa servono e quando secondo voi vengono usati?

Grazie a tutti per l'attenzione.

Cordiali saluti.

Marco Meoni.

-- Riferimenti --

[1] Gamma, Helm, et al, "Design Patterns - Elements of Reusable
Object-Oriented Software".
Addison-Wesley, 1995, ISBN 0-201-63361-2.

[2] http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52558


-- Codice --

class TestSingleton :

   # Create a class variable that will hold a reference
   # to the single instance of TestSingleton.

   instance = None

   # Define a helper class that will override the __call___
   # method in order to provide a factory method for TestSingleton.

   class TestSingletonHelper :

   def __call__( self, *args, **kw ) :

   # If an instance of TestSingleton does not exist,
   # create one and assign it to TestSingleton.instance.

   if TestSingleton.instance is None :
   object = TestSingleton()
   TestSingleton.instance = object

   # Return TestSingleton.instance, which should contain
   # a reference to the only instance of TestSingleton
   # in the system.

   return TestSingleton.instance

   # Create a class level method that must be called to
   # get the single instance of TestSingleton.

   getInstance = TestSingletonHelper()

   # Initialize an instance of the TestSingleton class.

   def __init__( self ) :

   # Optionally, you could go a bit further to guarantee
   # that no one created more than one instance of TestSingleton:

   if not TestSingleton.instance == None :
   raise RuntimeError, 'Only one instance of TestSingleton is
allowed!'

   #Continiue initialization...


# Test this implementation of the Singleton pattern.  All of the
# references printed out should have the same address.
if __name__=="__main__":
   for i in range( 10 ) :
   s = TestSingleton.getInstance()
   print s

# This call should raise a RuntimeError indicating
# that a single instance of TestSingleton already exists.

   TestSingleton()

--
Sbaush
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Re: IDE per Python

[Sbaush]

io uso kate per le cose "piccole"
quando serve un IDE kdevelop
--
Sbaush
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Re: IDE per Python

[Alan Franzoni]

Il 28/03/07, Gian Mario Tagliaretti<[EMAIL PROTECTED]> ha scritto:

Non riesco proprio a capire la produttività di VIM, sono una fila di
anni che ci provo senza risultati, nemmeno utilizzando cream, che in
teoria dovrebbe dare una grossa mano.

VIM e Emacs hanno indubbiamente la curva di apprendimento piu'
dispendiosa, credo che sia un fatto oggettivo riconosciuto, ma una
volta saltato l'ostacolo iniziale secondo me non c'e' confronto in
produttività, Emacs-VIM 4-0


Io non credo che la questione 'apprendimento' sia necessariamente
centrale. Penso che tutti si possano mettere a dare un'occhiata a un
qualcosa che poi può rendere parecchio. Il grosso dei problema è che
tutti questi editor appaiono datati rispetto a qualsiasi altra cosa
che si utilizzi.

Gvim, come ho già detto, apre una widget con dei menù abbastanza
piatti e brutti, ed è privo di qualsiasi schermata di configurazione
che sembri carina, con un terminale all'interno.

Emacs sembra che riesca a disabilitare qualsiasi funzionalità decente
di rendering. Sia Xemacs che emacs-gtk riescono a farmi vedere i pixel
dei caratteri sul mio schermo (un 15.4" da 1680x1050) .

Jedit mi pare faccia lo stesso, appena installato... mi sembra di
essere tornato ad una vecchia app per Windows 3.1 o una di quelle
applicazioni X che vedevo su Linux ai vecchi tempi, probabilmente il
look & feel delle gtk 1.x sarebbe migliore.

Cream l'ho installato in questo momento, pure... non capisco come si
attivino alcune modalità carine di Vim (tipo il visual mode) e il
packager di Edgy aveva probabilmente impoverito un po' troppo le sue
sigarette, cosicché non si riesce ad accedere all'help del pacchetto
né dai menù interni né dall'help di Ubuntu... ora me lo sto guardando
da web.

Comunque sono d'accordo con l'affermazione di Davide sui 'cervelli da
vim' e i 'cervelli da emacs'... era dai tempi delle diatribe C64 vs
Spectrum che non vedevo tanto fervore e tanta voglia di scarnificare
gli avversari ^_^

--
Alan Franzoni <[EMAIL PROTECTED]>
-
GPG Key Fingerprint:
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Re: IDE per Python

[Alan Franzoni]

Neanch'io, e tanto meno OS/X.

E le sbrodolate per Vi/m che si sono sentite... bleah, meglio che sto zitto.


Tu, se non ricordo male, eri un fan dello 'stateless' e per questo
dicevi di non amare il 'command mode' di vim, ed io ero in linea di
massima d'accordo con te.. finché non l'ho provato un po' seriamente!

C'è poco da fare, anche il command mode è utile. Di fatto, capita
raramente di dover tenere premuto più di un tasto contemporaneamente
(al contrario dei ctrl+alt+shift+qualcos'altro di altri editor) e di
fatto, quindi, la mente può mantenersi concentrata su un solo compito
alla volta.

Purtroppo vim ed emacs sembrano (verosimilmente: sono) due editor di
testi ottimi e configurabili, ma nati nel passato come editor in modo
puramente testuale e 'vagamente' adattati agli ambienti grafici come
X.

Voglio dire: in Gvim, devo comunque editarmi il file .vimrc per
salvare le impostazioni, nonostante (alcune) impostazioni siano
disponibili da menù... non c'è modo di salvarle... e in generale mi
pare di avere un widget di contorno con un terminale all'interno (e in
effetti mi pare che i menu di gvim non facciano altro che 'sparare' un
comando al command-mode di vim)

Discorso simile per emacs nelle sue incarnazioni grafiche. E
purtroppo, anche l'occhio vuole la sua parte, specialmente quando deve
stare ore e ore davanti ad uno schermo :-(

Ovviamente non sto incolpando nessuno, sono tutti software liberi e
c'è ben poco da lamentarsi, ma mi pare davvero strano che nonostante
ci siano le basi non si è arrivati a sviluppare un pezzo di software
così centrale come un editor.

Nella mia idea, un editor dovrebbe essere facile da usare fin
dall'inizio, la complessità dovrebbe emergere man mano che si
ricercano funzioni più avanzate... non posso mica mettermi a leggere
un manuale per scrivere quattro caratteri. Ricordo le prime volte
usavo vi non riuscivo neanche a capire come si immetteva il testo
(vabbè, era il 1998 se non sbaglio, quando installai la mia prima
Slackware ). E non mi pare il massimo doversi andare a leggere il
manuale ogni volta che si cerca un comando; ok, è utile che sia
accessibile anche dal command-mode, ma ci dovrebbe essere anche un
menu che permetta di raggiungere le funzioni meno usate.

Vabbè, alla fine di questa riflessione che cosa avrò mai capito? O
devo aspettare che la Apple cambi atteggiamento nei confronti
dell'ambiente (oppure che la mia anima ecologista si diradi) e
pigliarmi un Mac... oppure adeguarmi. Potrei anche tentare di
scrivermi un editor di testo come lo voglio, ma non credo di essere
ancora in grado.



--
Alan Franzoni <[EMAIL PROTECTED]>
-
GPG Key Fingerprint:
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[Paolo Amodio]

Il giorno 28/mar/07, alle ore 13:17, enrico franchi ha scritto:


On 3/28/07, Paolo Amodio <[EMAIL PROTECTED]> wrote:




Bah... sarebbe interessante sapere quanti sviluppatori Python
utilizzino Win come SO ?
Non credi ?


Più di quanto si pensi. Ad ogni modo TM è un editor multi-linguaggio,
Non solo lo trovo il miglior editor per Python: è indubbiamente il
miglior editor per Ruby e a mio avviso lo è anche per XHTML e CSS. PHP
non lo uso, ma ha un sacco di funzioni eccellenti (e messo insieme con
quello che hanno su XHTML penso potrebbe vincere la palma anche li).

Supporta in modo eccellente anche Haskell e OCaml. Ma anche il
supporto per C e C++ è parecchio buono (anche se questi linguaggi in
qualche modo non hanno features particolari per un editor, resta il
fatto che TM con il suo modo velocizzato di inserire codice e ccelle
anche qui).

TM è in pratica comodo ad *ogni* programmatore. Ah, e non ho parlato
del fantastico supporto per Latex.



--  
-enrico

___
Python mailing list
Python@lists.python.it
h


Mi sta venendo l'acquolina in bocca... ;-)

Credo che ora andrò a scaricarmelo (anche se uso BBEdit con  
soddisfazione...)



Paolo Amodio
[EMAIL PROTECTED]
www.dixienet.it



___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Re: Re: IDE per Python

[Davide Lo Re]

Gian Mario Tagliaretti ha scritto:
> Non riesco proprio a capire la produttività di VIM, sono una fila di
> anni che ci provo senza risultati, nemmeno utilizzando cream, che in
> teoria dovrebbe dare una grossa mano.
Io ormai ho maturato la convinzione che alcuni cervelli sono progettati in
un modo e altri in uno completamente diverso. OK, progettato non si dice
che fa troppo creazionismo e noi scienziati non dovremmo parlarne :-D
Pero' e' incredibile come io (VIm-ista da molto) abbia molte volte provato a
usare emacs e... semplicemente mi scoraggia.
Proprio giorni fa ci ho riprovato, mi sono letto un bel po' di pagine di
manuale, i comandi basilari, eccetera.
Non ho ancora capito come cancellare una linea in un modo veloce, ovvero con
poche pressioni di tasti.
Poi che sia potente non lo metto in dubbio, e capisco che chi ha un
cervello "alla emacs" non ne puo' fare a meno.
Ma io se devo trovare un difetto a vim trovo solo quello che, nonostante
abbia numerosi modi e linguaggi per essere "scriptato" (oltre che il
linguaggio nativo, perl, *python*, ruby, non so se altri) lo scripting mi
sembra sempre confuso. Mi piacerebbe avere una specie di "toolkit" per vim,
che renda facile creare una sorta di "popup menu" senza impazzire.
Ma forse e' solo fantascienza, o forse mi sono solo impegnato poco nello
scripting.
> VIM e Emacs hanno indubbiamente la curva di apprendimento piu'
> dispendiosa, credo che sia un fatto oggettivo riconosciuto, ma una
> volta saltato l'ostacolo iniziale secondo me non c'e' confronto in
> produttività, Emacs-VIM 4-0
Beh forse vim all'inizio non e' troppo difficile. impari che con I
modifichi, con  smetti di modificare e :wq salva e puoi vivere.
Ovviamente non ti godi il resto :D
Ma emacs all'inizio e' davvero un'impresa, per me almeno lo e' stato
(impresa non risolta, tra l'altro)
> VIM lo vedo un po' come la Slackware degli "editor avanzati", fa tendenza.
Mi sembra restrittivo: la potenza c'e', e' innegabile. Il look&feel, come
dice il nome, e' questione di gusti.
> ciao
Ciao :-)
Davide


___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Re: IDE per Python

[Nicola Larosa]

> Nicola Larosa:
>> E le sbrodolate per Vi/m che si sono sentite... bleah, meglio che sto
>> zitto.

Gian Mario Tagliaretti wrote:
> Se non fossimo entrambi sposati e con figli ti chiederei la mano

Beh, magari ci sarebbe stata qualche altra "piccola" condizione
insoddisfatta. ;-D


> Non riesco proprio a capire la produttività di VIM, sono una fila di
> anni che ci provo senza risultati, nemmeno utilizzando cream, che in
> teoria dovrebbe dare una grossa mano.

Argh, questa è una brutta notizia, contavo di provare seriamente Cream
appena passato a Kubuntu Feisty, principalmente per il supporto di Vim 7.0
a RestructuredText, e speravo che Cream mi evitasse l'orrore fisiognomico
del command mode, sarebbe stata una bella soddisfazione usare Vim come un
qualsiasi altro editor. :-}


> VIM e Emacs hanno indubbiamente la curva di apprendimento piu'
> dispendiosa, credo che sia un fatto oggettivo riconosciuto, ma una
> volta saltato l'ostacolo iniziale secondo me non c'e' confronto in
> produttività, Emacs-VIM 4-0

Io ho provato molti anni fa a usare il semplice vi, ho rinunciato presto, e
non mi ci sono mai più avvicinato, se non costretto. L'unico comando che
ricordo (forse) è quello di uscita.

Invece Emacs, e XEmacs, ho provato a usarli a più riprese negli anni, ma
non mi ci trovo proprio, sono *troppo* poco intuitivi. Come diceva
qualcuno, la potenza è nulla senza controllo, e io ho anche una certa età,
mi sa che ormai non glie la fo più a domare la bestia. ;-)


> VIM lo vedo un po' come la Slackware degli "editor avanzati", fa tendenza.

In un certo senso. Però almeno con Slackware Linux lo impari (l'ho usata
per un paio d'anni), poi la molli perché è scomoda. vi no, ti distorce il
cervello, e una volta che sei deformato non riesci a mollarlo più.


> Visto che dalle IDE si è passati anche agli editor, non ho ancora
> visto nominato Jedit (ok ok è in java) che tramite un sistema di
> plugin molto funzionale lo rende un editor molto comodo, soprattutto
> per chi è abituato ad Emacs, nessuno lo usa?

Ho provato anche quello, non è male, ma sono allergico ai patocconi in
Java, li evito se non sono proprio indispensabili.

Come detto da qualcuno, mi trovo a usare sempre più Kate, non è male. Per
Python uso Eric, e per gli edit spiccioli l'editor interno del sempre
ottimo Midnight Commander, il mio file manager, più che preferito, direi
ormai genetico, neanche Krusader riesce a scalzarlo.


-- 
Nicola Larosa - http://www.tekNico.net/

Life is mainly a trade-off between money and time.
You must pay in money or time.
You will be paid in money or time.
 -- Gary North, October 2006

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Re: IDE per Python

[Gian Mario Tagliaretti]

2007/3/28, Nicola Larosa <[EMAIL PROTECTED]>:


E le sbrodolate per Vi/m che si sono sentite... bleah, meglio che sto zitto.


Se non fossimo entrambi sposati e con figli ti chiederei la mano
non ho scritto io la stessa identica cosa solo per non aizzare le
folle.

Non riesco proprio a capire la produttività di VIM, sono una fila di
anni che ci provo senza risultati, nemmeno utilizzando cream, che in
teoria dovrebbe dare una grossa mano.

VIM e Emacs hanno indubbiamente la curva di apprendimento piu'
dispendiosa, credo che sia un fatto oggettivo riconosciuto, ma una
volta saltato l'ostacolo iniziale secondo me non c'e' confronto in
produttività, Emacs-VIM 4-0

VIM lo vedo un po' come la Slackware degli "editor avanzati", fa tendenza.

Visto che dalle IDE si è passati anche agli editor, non ho ancora
visto nominato Jedit (ok ok è in java) che tramite un sistema di
plugin molto funzionale lo rende un editor molto comodo, soprattutto
per chi è abituato ad Emacs, nessuno lo usa?

ciao
--
Gian Mario Tagliaretti
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[Enrico Franchi]

On 28/mar/07, at 17:41, [EMAIL PROTECTED] wrote:

Anche perchè (ok, sto per farmi TANTI nemici!) ancora non sono  
riuscito ad apprezzare TM... ;-)


E' una cosa graduale.

-enrico

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Re: IDE per Python

[Y3s]

Ecco qua, come vado a permalosità? ;-P


Puoi fare di meglio...mediocre diciamo ;-)


PS a me MacOS X piace MOLTO! (si, ce lo aggiungo: e chissenefrega)

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Re: IDE per Python

[Nicola Larosa]

De Santis Luca wrote:
> Occhio che i MacUser sono molto permalosi

Non scherzo neanch'io, e infatti parliamo un po' di te.

Per cominciare, se puoi evitare il top posting è meglio: le repliche vanno
*dopo* il testo citato, così come le risposte vengono dopo le domande, di
solito. Poco importa se il programma di posta ha questo comportamento
assurdo di default, le impostazioni sono lì per essere cambiate, quando
serve. E qui *serve*.

Inoltre, i messaggi HTML in lista sono da evitare, se possibile. E` vero
che hai aggiunto anche una copia solo testo, ma prova a guardarla, e vedi
che disastro che è venuto fuori.

Infine, Hotmail e Live Messenger, sei cuggino di Tafazzi per caso? Pure a
mmio cuggino!

Ecco qua, come vado a permalosità? ;-P

(Mmh, devo migliorare le mie tecniche BOFH, mi sto un po' arrugginendo...)


-- 
Nicola Larosa - http://www.tekNico.net/

Life is mainly a trade-off between money and time.
You must pay in money or time.
You will be paid in money or time.
 -- Gary North, October 2006


___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[Enrico Franchi]

On 28/mar/07, at 13:35, Y3s wrote:

Scherzi a parte, wine ad oggi fa girare centinaia di applicazioni  
windows, ed è un lavoraccio infame anche per la penosissima  
architettura microsoft..



non conosco cocoa, ma tempo fa smanettai con GNUStep, che come  
architettura dovrebbe essere la stessa...semplice, lineare e chiaro  
come tutto ciò che fa parte del mondo Mac...


Anche ci sono diversi gotchas non architetturali. I .nib non sono  
letti da GNUStep (non lo erano). Quindi gli sviluppatori su MacOS X  
devono 'approvare' ogni modifica ad un nib e propagarla ai non OS X.


Poi ci possono essere vari Framework che su OS X trovi e altrove non  
sai bene come fare (se non aggiungendo layer software).


Insomma, concordo che alcuni oggetti (come TM) possono nascere solo  
in ambito Mac, ma una volta definite le caratteristiche "alla mac",  
qualcuno di buona volontà potrebbe eseguire il porting senza  
stravolgerne le doti..


E' un lavoraccio: si fa molta meno fatica a configurare Emacs o vim a  
seconda dei gusti.



-enrico

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[Enrico Franchi]

On 27/mar/07, at 19:20, solimo wrote:


L'ho scaricato (30 gg di prova), vediamo che impressioni ne avro'.


Questo non lo avevo letto. Il primo consiglio che voglio darti è:


Il secondo è: esplora i menu, scopri le sue potenzialità.

C'è anche un libro su TM che io ancora non ho.




-enrico

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

RE: [Python] Re: IDE per Python

[De Santis Luca]

Occhio che i MacUser sono molto permalosi

> Date: Wed, 28 Mar 2007 18:09:52 +0200> From: [EMAIL PROTECTED]> To: 
> python@lists.python.it> Subject: [Python] Re: IDE per Python> > [EMAIL 
> PROTECTED] wrote:> > Anche perchè (ok, sto per farmi TANTI nemici!) ancora 
> non sono riuscito ad apprezzare TM... ;-)> > Neanch'io, e tanto meno OS/X.> > 
> E le sbrodolate per Vi/m che si sono sentite... bleah, meglio che sto zitto.> 
> > > -- > Nicola Larosa - http://www.tekNico.net/> > Yes, there are personal 
> limits, usually physical but sometimes mental.> Rocket science is a 
> restricted profession. But there are so many potent-> ial areas of progress 
> in every person's life that there is no excuse> for not pushing these limits 
> outward. -- Gary North, October 2006> > > 
> ___> Python mailing list> 
> Python@lists.python.it> http://lists.python.it/mailman/listinfo/python
_
Sai cosa è successo oggi?
http://notizie.msn.it___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Re: IDE per Python

[Nicola Larosa]

[EMAIL PROTECTED] wrote:
> Anche perchè (ok, sto per farmi TANTI nemici!) ancora non sono riuscito ad 
> apprezzare TM... ;-)

Neanch'io, e tanto meno OS/X.

E le sbrodolate per Vi/m che si sono sentite... bleah, meglio che sto zitto.


-- 
Nicola Larosa - http://www.tekNico.net/

Yes, there are personal limits, usually physical but sometimes mental.
Rocket science is a restricted profession. But there are so many potent-
ial areas of progress in every person's life that there is no excuse
for not pushing these limits outward. -- Gary North, October 2006


___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[[EMAIL PROTECTED]]

> Da: "Lawrence Oluyede" <[EMAIL PROTECTED]>
> Data: Wed, 28 Mar 2007 14:19:00 +0200
> A: "Discussioni generali sul linguaggio Python" 
> Oggetto: Re: [Python] IDE per Python
>
> > Insomma, concordo che alcuni oggetti (come TM) possono nascere solo
> > in ambito Mac, ma una volta definite le caratteristiche "alla mac",
> > qualcuno di buona volontà potrebbe eseguire il porting senza
> > stravolgerne le doti...
> 
> Aspettiamo quel qualcuno allora ;-)
> 

NON mi offro volontario! :-)

Anche perchè (ok, sto per farmi TANTI nemici!) ancora non sono riuscito ad 
apprezzare TM... ;-)


SERVIZIO VOICE: TELEFONA e INVIA SMS dal tuo computer a tariffe vantaggiose! 
Scopri come telefonare e videochiamare gratis da pc a pc.
http://voice.repubblica.it



___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[Lawrence Oluyede]

Insomma, concordo che alcuni oggetti (come TM) possono nascere solo
in ambito Mac, ma una volta definite le caratteristiche "alla mac",
qualcuno di buona volontà potrebbe eseguire il porting senza
stravolgerne le doti...


Aspettiamo quel qualcuno allora ;-)


--
Lawrence, oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] email, allegati e pigrizia

[[EMAIL PROTECTED]]

> Perfetta, funziona benissimo.
>   
'biabam' no?
sotto debian è pacchettizzato

Ciao
Alessandro

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[Y3s]

Il giorno 28/mar/07, alle ore 13:24, enrico franchi ha scritto:


On 3/28/07, Y3s <[EMAIL PROTECTED]> wrote:


E wine? :-)


Quanti anni è che ci stanno lavorando? E comunque anche li, non è  
*tutto*.

E il parco software di windows è talmente più ampio da rendere la cosa
molto più appetibile.


Più o meno da quando lavorano su windows ;-)
Scherzi a parte, wine ad oggi fa girare centinaia di applicazioni  
windows, ed è un lavoraccio infame anche per la penosissima  
architettura microsoft..non conosco cocoa, ma tempo fa smanettai con  
GNUStep, che come architettura dovrebbe essere la stessa...semplice,  
lineare e chiaro come tutto ciò che fa parte del mondo Mac...
Insomma, concordo che alcuni oggetti (come TM) possono nascere solo  
in ambito Mac, ma una volta definite le caratteristiche "alla mac",  
qualcuno di buona volontà potrebbe eseguire il porting senza  
stravolgerne le doti...___

Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[enrico franchi]

On 3/28/07, Y3s <[EMAIL PROTECTED]> wrote:


E wine? :-)


Quanti anni è che ci stanno lavorando? E comunque anche li, non è *tutto*.
E il parco software di windows è talmente più ampio da rendere la cosa
molto più appetibile.


--
-enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[enrico franchi]

On 3/28/07, Alan Franzoni <[EMAIL PROTECTED]> wrote:


> http://e-texteditor.com/

Curioso... farò partire un VMWare con Windoze e lo proverò


Non ci assomiglia per nulla, in realtà.



Il mio cruccio fondamentale è che sto cercando da un po' un editor
'generalista' che mi soddisfi veramente... e non lo trovo :-(


Tu vuoi TextMate. Ma credo che usare MacOS X sia un vantaggio di per
se, e TM ne è una killer application.

--
-enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[enrico franchi]

On 3/28/07, Lawrence Oluyede <[EMAIL PROTECTED]> wrote:


Certo, ma significa farlo usando un minimo comune denominatore. Cosa
che magari a lui non interessava. TM secondo me è così cool proprio
perché è focused su una sola piattaforma. Se fosse multi probabilmente
attrarrebbe 10 volte le persone che ci lavorano e diventerebbe un
bloat in un bananosecondo


+1

Sulle applicazioni 'desktop' che si usano veramente, il multiplatform
è una mossa in se molto rischiosa: o si hanno staff immensi per cui in
effetti si mantengono due versioni diverse del programma con in comune
solo il core (leggi Adobe), oppure se si vuole un unico sw per tutte
le piattaforme, crei qualcosa che non eccelle in nessuna.

Jack of all trades, master of none.

Con il risultato che uno sceglie dell'altro.

--
-enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[enrico franchi]

On 3/28/07, Paolo Amodio <[EMAIL PROTECTED]> wrote:




Bah... sarebbe interessante sapere quanti sviluppatori Python
utilizzino Win come SO ?
Non credi ?


Più di quanto si pensi. Ad ogni modo TM è un editor multi-linguaggio,
Non solo lo trovo il miglior editor per Python: è indubbiamente il
miglior editor per Ruby e a mio avviso lo è anche per XHTML e CSS. PHP
non lo uso, ma ha un sacco di funzioni eccellenti (e messo insieme con
quello che hanno su XHTML penso potrebbe vincere la palma anche li).

Supporta in modo eccellente anche Haskell e OCaml. Ma anche il
supporto per C e C++ è parecchio buono (anche se questi linguaggi in
qualche modo non hanno features particolari per un editor, resta il
fatto che TM con il suo modo velocizzato di inserire codice e ccelle
anche qui).

TM è in pratica comodo ad *ogni* programmatore. Ah, e non ho parlato
del fantastico supporto per Latex.



--
-enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[Y3s]

Portare tutto Cocoa è grosso modo come chiedere di portare le WinAPI.


E wine? :-)

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[enrico franchi]

On 3/28/07, Alan Franzoni <[EMAIL PROTECTED]> wrote:


Io vorrei fare una domanda 'estemporanea': sento parlare
fantasticamente di questo TextMate più o meno da tutti. E tuttavia
questo software rimane disponibile solo per MacOS X.


Vero, e non  può che essere così. Nasce in MacOS X ed è un esempio
lampante della sua filosofia di utilizzare le basi unix attraverso
un'interfaccia più umana (ma senza introdurre un layer troppo spesso
fra l'interfaccia e le basi, in modo tale che sia facile agire
direttamente con facilità sulle basi).


Voglio dire: fa leva su qualche funzionalità o libreria altamente
specializzata di OS X che sarebbe impossibile - o troppo complesso- da
replicare su Windows o Linux?


Utilizza Cocoa, la libreria principale di sviluppo sotto MacOS.
Già questo renderebbe complicato un port (anche per le varie
estensioni, per esempio la possibilità di accedere alle funzionalità
per renderizzare html, pdf e compagnia bella).

Portare tutto Cocoa è grosso modo come chiedere di portare le WinAPI.
Una parte di Cocoa (che in effetti è più un gemello che un port) è
disponibile ovunque e si chiama GNUStep. Ma *tutto* Cocoa non lo è.

Ci si potrebbe tuttavia chiedere una cosa: TextMate nasce con Cocoa.
Prima di TM l'altro editor altrettanto flessibile e configurabile era
solo Emacs (che in effetti si basa su Lisp). Io credo che Cocoa sia
parte integrante di come è pensato TM: credo che senza MacOS X e
Cocoa, TM non sarebbe mai nato.

Di per se non ha funzionalità non replicabili con altre librerie, ma
nessuno lo aveva fatto prima (se non Emacs) e nessuno lo ha ancora
fatto. Ma nemmeno lontanamente. In qualche modo credo che sia una
questione più filosofica che tecnica.



 Oppure è solo un vezzo degli autori - e
in tal caso mi pare un vezzo dispendioso, in quanto il mercato Windows
credo offrirebbe entrate notevolmente maggiori!


In realtà gli sviluppatori ci mangiano più che bene così. Ma non sono
esosi: se anche lo vendessero al doppio del prezzo, la gente lo
comprerebbe comunque. Eppure non lo fanno.


--
-enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] IDE per Python

[enrico franchi]

On 3/27/07, solimo <[EMAIL PROTECTED]> wrote:


Smultron nella sua semplicita' mi torna utile quando occasionalmente sono
lontano dal terminale, lo citavo come metro di paragone rispetto agli altri
di cui ho solo sentito parlare.


Mi spiego, come metro di paragone è poco significativo. Più o meno
qualunque altra cosa fa di più.


--
-enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Re: IDE per Python

[enrico franchi]

On 3/27/07, Enrico 'Henryx' Bianchi <[EMAIL PROTECTED]> wrote:


Beh, intanto si potrebbe mettere questa: per avere l'autocompletamento,
premere CTRL + P o CTRL + SHIFT + P (Vim 7)


Vero. Pensa che per OS X distribuisco anche una build di Vim. Sigh,
quanto tempo che non lo uso.


Cosa sarebbe?


Per esempio quando scrivi ( lui scrive () e ti mette il cursore in
mezzo. Idem per altre parentesi e '' e "". Quando ti ci abitui fa un
sacco comodo.


--
-enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Re: email, allegati e pigrizia

[Nicola Larosa]

Sandro Dentella wrote:
> Scusate se chiedo in lista uno sconto alla minuziosa lettura della 
> documentazione del modulo 'email',

"minuziosa", basta dare un'occhiata agli esempi. ;-P


> ma immagino che qualcuno abbia degli esempi funzionanti di spedizione di
> allegati pdf in python...

Non fa differenza se alleghi PDF o altri tipi di file.


> Google mi ha aiutato poco, c'è qualcosa ma parziale e non sono arrivato
> in porto...

Il secondo esempio nella doc potrebbe aiutarti:

http://docs.python.org/lib/node162.html


-- 
Nicola Larosa - http://www.tekNico.net/

Yes, there are personal limits, usually physical but sometimes mental.
Rocket science is a restricted profession. But there are so many potent-
ial areas of progress in every person's life that there is no excuse
for not pushing these limits outward. -- Gary North, October 2006

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] email, allegati e pigrizia

[Sandro Dentella]

On Wed, Mar 28, 2007 at 09:14:19AM +0200, Stefano wrote:
> Sandro Dentella ha scritto:
> >
> >Se no mi costa meno chiamare 'mutt -a' ;-)
> >
> 
> Ciao Sandro,
> 
> ti riporto qui di seguito un breve listato che uso per inviare delle 
> mail con allegato, non è molto commentato spero sia comunque comprensibile.

Perfetta, funziona benissimo.

Grazie
sandro
*;-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] email, allegati e pigrizia

[Stefano]

Sandro Dentella ha scritto:


Se no mi costa meno chiamare 'mutt -a' ;-)



Ciao Sandro,

ti riporto qui di seguito un breve listato che uso per inviare delle 
mail con allegato, non è molto commentato spero sia comunque comprensibile.



import os

import smtplib
from email.MIMEMultipart import MIMEMultipart
from email.MIMEBase import MIMEBase
from email.MIMEText import MIMEText
from email.Utils import COMMASPACE, formatdate
from email import Encoders



def sendMail(mittente, to, subject, text, files=[],server="localhost"):
assert type(to)==list
assert type(files)==list

msg = MIMEMultipart()
msg['From'] = mittente
msg['To'] = COMMASPACE.join(to)
msg['Date'] = formatdate(localtime=True)
msg['Subject'] = subject
#~ se è necessaria la conferma di lettura
msg['Disposition-Notification-To'] = mittente

msg.attach( MIMEText(text) )

for file in files:
part = MIMEBase('application', "octet-stream")
part.set_payload( open(file,"rb").read() )
Encoders.encode_base64(part)
part.add_header('Content-Disposition', 'attachment; filename="%s"'
   % os.path.basename(file))
msg.attach(part)

smtp = smtplib.SMTP(server)
smtp.sendmail(fro, to, msg.as_string() )
smtp.close()


if __name__ == '__main__':

smpt_server = 'mail.dominio.it'
mittente = 'Mittente <[EMAIL PROTECTED]'
destinatari = ['[EMAIL PROTECTED]',]
oggetto = "Oggetto"
corpo = "Cordiali Saluti \n\n Mittente"
pathname = os.getcwd()
file_allegato = pathname+"\\"+filename+".pdf"
sendMail(mittente, destinatari, oggetto, corpo, [file_allegato], 
smtp_server)





grazie
*:-)


Prego ;-)

Saluti
Stefano


--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
Prestiti e Finanziamenti con un semplice click, scopri subito se sei 
finanziabile cliccando qui
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2910&d=28-3
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python