[Python] Epic Online Investment Banking Training Course Bundle
This Investment Banking Training course is an Epic bundle of 99 courses with 500+ hours of video tutorials and Lifetime Access. This is not all, you also get verifiable certificates (unique certification number and your unique URL) when you complete these courses.This online investment banking course is the most comprehensive Investment Banking Preparation material on the planet! It is designed for students and professionals who want to master investment banking skills. The resources included here are from basics tutorials to super advanced concepts of Investment Banking.These set of core courses on Investment Banking start from the basic operations at an Investment Bank to imparting core practical training on the same. Some of the core courses include analyst accounting, valuations, public comps, discounted cash flows or DCF Modeling, IPO modeling, Private Equity Modeling, LBO Modeling, Equity Research, Pitch book, Fixed Income and many more. Please note that this epic bundle on Investment Banking Training is provided by eduCBA (Global Online Training Experts) and I am one of the co-founders at eduCBA. For more information related to this training material you can visit to our website: http://www.wallstreetmojo.com/investment-banking-training- course/ ___ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
Re: [Python] Baco di cgi o mio?
On Fri, 08 May 2009 17:06:58 +0200, Pietro Battiston wrote:
> Il giorno ven, 08/05/2009 alle 16.57 +0200, Zanon Samuele ha scritto:
>> non credo che funzioni perchè il comando non viene eseguito al seguito
>> dell'invio di un form...
>
> Veramente lo stesso identico problema lo ho in un cgi che ha appena
> ricevuto un form bello pieno, e l'ho riprodotto in due linee di script
> solo per comodità. Se fai un "print cgi.FormContentDict()", ottieni un
> pacifico "{}".
te lo riproduco in ancora meno linee ;)
In [20]: from UserDict import UserDict
In [21]: list(iter(UserDict()))
in soldoni la classe UserDict, da cui cgi.FormContentDict deriva non è
iterabile (non definisce __iter__ e la sua __getitem__ non funziona con
gli interi) quindi non puoi fare ( i for i in cgi.FormContentDict())
Detto questo IMHO è un bug, non il fatto che UserDict non sia iterabile,
quanto il fatto che FormContentDict non derivi da
UserDict.IterableUserDict o meglio ancora da dict.
ciao
--
Mi contraddico, forse?
Ebbene mi contraddico (sono vasto, contengo moltitudini)
-- Walt Whitman
___
Python mailing list
[email protected]
http://lists.python.it/mailman/listinfo/python
Re: [Python] Differenze di date tra un file e la data attuale
On Thu, 2009-11-26 at 12:00 +0100, Zanon Samuele wrote: > ciao a tutti... sto facendo un scriptino di manutenzione in python, > solo che sono arrivato ad un punto che non riesco a risolvere: dovrei > controllare la differenza tra la data attaule del server e la data di > modifica del file... lo script va messo su un server ftp e mi serve > per eliminare i file più vecchi di 48 ore... mi potete dare una mano? > sono riuscito a fare il ciclo che mi recupera l'intero percorso del > file, ma non riescoa fare la differenza. [snip] > come proseguo? > ciao e grazie mille ciao vediamo se riesco a darti qualche hint 1. il modulo os ti permette di sapere quando è stato modificato un certo file, os.stat 2. puoi convertire uno unix timestamp in un datetime 3. la differenza tra due datetime è un timedelta, quest'ultimo rappresenta un intervallo temporale e ha dei comodoi attributi per rappresentarlo in secondi, giorni, millisecondi etc HTH signature.asc Description: This is a digitally signed message part ___ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
Re: [Python] Usare Unicode e charset
On Thu, 2009-12-03 at 11:12 +0100, Daniele Varrazzo wrote: [snip] > Le mail che hai ricevuto penso abbiano chiarito i tuoi problemi. Ti > segnalo un articolo discorsivo e interessante per farsi un po' una ragione > degli encoding e dell'unicode, non specifico per Python: > > http://www.joelonsoftware.com/articles/Unicode.html E io, per farci un po' di pubblicità in vista del pycon4 :), rilancio con: http://www.pycon.it/conference/talks/unicode-python http://www.pycon.it/conference/talks/python-e-unicode-ovvero-there-aint-no-such-thing-p HTH -- Mi contraddico, forse? Ebbene mi contraddico (sono vasto, contengo moltitudini) -- Walt Whitman signature.asc Description: This is a digitally signed message part ___ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 12:40 +0100, Daniele Varrazzo wrote:
> On Fri, 4 Dec 2009 12:34:15 +0100, Ernesto wrote:
>
> > Per ora il modo più semplice che ho trovato è:
> >
> > import os
> > f=open(infile)
> > for i in f:
> > l=(i.strip()).split("\t")
> > out=open(l[2]+".txt","a")
> > out.write(i)
> > out.close()
> > f.close()
> >
> > Lanciato su un file di 15GB il tempo necessario per completare il
> > tutto è superiore ai 2 giorni.
> > C'è un modo per velocizzare il processo?
>
> Perchè apri e chiudi i file ad ogni riga? Ogni volta gli fai flushare il
> buffer. Lasciali aperti:
oltre a questo (che cmq porterà i maggiori benefici) potremmo guadagnare
qualcosa anche con:
1) aprire il file da 15GB in modalità binaria (utile solo se siamo sotto
windows e forse anche sotto mac)
2) provare ad aumentare il buffer dei file (forse più utile quello in
scrittura?)
3) se le linee nel file hanno lunghezza fissa non usare il for ma andare
di f.read(qualchekb)
bye
signature.asc
Description: This is a digitally signed message part
___
Python mailing list
[email protected]
http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 12:49 +0100, Ernesto wrote: > > > > > Perchè apri e chiudi i file ad ogni riga? Ogni volta gli fai > > flushare il > > buffer. Lasciali aperti: > > > > > > Ho provato a lasciarli aperti ma ho ottenuto un errore che mi indicava > che avevo più di 24 file aperti. > In realtà i file di output che mi aspetto sono più di 1000. puoi aumentare il numero di file aperti contemporanemante, su che os stai lavorando? signature.asc Description: This is a digitally signed message part ___ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 13:10 +0100, Daniele Varrazzo wrote: > On Fri, 04 Dec 2009 12:59:52 +0100, David Mugnai wrote: > > > 3) se le linee nel file hanno lunghezza fissa non usare il for ma andare > > di f.read(qualchekb) > > file.__iter__ fa questo dietro le quinte. Infatti se vuoi davvero creare > un programma filtro in Python devi non solo usare "python -u", ma devi > anche sostituire il for con: > > while 1: > line = f.readline() > if not line: break > ... non mi sono spiegato, se le righe hanno lunghezza prefissata puoi leggere a blocchi, risparmiare la split per trovare il carattere e risparmiare alla readline di python di cercare il \n signature.asc Description: This is a digitally signed message part ___ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 13:39 +0100, Daniele Varrazzo wrote: > On Fri, 4 Dec 2009 13:32:56 +0100, Marco Beri wrote: [snip] > > Ok, attento in uscita dal loop: devi scrivere le ultime righe rimaste > nel > > dizionario. > > > > E ricordati di avere un limite massimo di righe tale da gestire anche la > > situazione peggiore:\ > > MAX_LENGTH * MAX_NUM_FILE * (MAX_RIGHE - 1) > > > > Murphy è sempre in agguato :-) > > Io infatti avrei salvato tutti i dizionari dopo un numero prefissato di > righe lette dal file di input. In questo modo l'occupazione di memoria è > controllata e le prestazioni credo siano in linea (qualche file potrebbe > avere poche righe, ma se su 1000 file aperti si scrivono 1M di righe > statisticamente siamo lì). Credo sia anche molto più semplice da scrivere e > meno soggetto ad errori. non stiamo reinventando quello che già fa il sistema operativo con il file buffer? invece di scrivere logica addizionale che mima quello che fa già il kernel potremmo provare ad aprire i file con bufsize=10M :) signature.asc Description: This is a digitally signed message part ___ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 13:12 +0100, Ernesto wrote: > > > > > puoi aumentare il numero di file aperti contemporanemante, su che os > > stai lavorando? > > > > > > Su OS X 10.5. quindi uno unix based, ci sarà sicuramente un comando per aumentare il numero permesso di file aperti contemporaneamente, magari è proprio ulimit, ma io e OS/X siamo su due pianeti diversi quindi passo la palla a chi lo conosce per bene. signature.asc Description: This is a digitally signed message part ___ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 15:08 +0100, Daniele Varrazzo wrote: [snip] > No, non stiamo reinventando i buffer: li stiamo usando meglio. hmm, più che meglio forse in maniera diversa (e magari più opportuna a seconda del problema) > > 24 è un limite basso, ma se il numero di file potenzialmente da scrivere è > estremamente alto, scrivere un programma che garantisca l'uso di un numero > controllato di file aperti mi sembra sensibile quanto scrivere un programma > che non carichi tutto il file in memoria. Uno script che per girare ha > bisogno che gli venga impostato ulimit mi sembra abbia dei problemi, quanto > uno che per processare 1GB di file ha bisogno di 1GB di memoria. se il limite è impostato ad capocchiam non vedo un problema ad utilizzare ulimit; rileggendo una mail dell'OP, lui dice: > In realtà i file di output che mi aspetto sono più di 1000. che è un paio di ordini di grandezza sopra a 24 quindi è molto probabile che una strategia per limitare i file aperti serva in ogni caso. signature.asc Description: This is a digitally signed message part ___ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
Re: [Python] split di file di grandi dimensioni
On Fri, 2009-12-04 at 14:56 +0100, Manlio Perillo wrote: > Nicola Larosa ha scritto: > > [...] > > David Mugnai wrote: > >> non stiamo reinventando quello che già fa il sistema operativo con il > >> file buffer? invece di scrivere logica addizionale che mima quello che > >> fa già il kernel potremmo provare ad aprire i file con bufsize=10M :) > > > > Con quello istruisci il buffering fatto dall'IO in Python (basato su > stdio del C), non il sistema operativo. > > Non c'è modo diretto per dire al kernel quanta memoria usare per il > buffering di un file, che io sappia (e di certo POSIX non lo prevede). hai ragione! mi ricordavo male. Probabilmente quel buffer influenza il numero di flush che python chiama, ma se queste finiscano sul disco oppure no lo decide il kernel. signature.asc Description: This is a digitally signed message part ___ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
Re: [Python] Volontari per un seminario su Python a Bologna
On Mon, 07 Dec 2009 10:40:44 +0100, Massimo Capanni wrote: > Mi informavo semplicemente per il fatto che poteva essere una cosa > carina organizzare qualcosa ogni tanto (come i Perl Mongers) > > Io sono di Grosseto. presente, Campi Bisenzio; e sempre a Campi c'e' Develer in cui lavorano diversi pythonisti più o meno famosi. -- Mi contraddico, forse? Ebbene mi contraddico (sono vasto, contengo moltitudini) -- Walt Whitman ___ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
Re: [Python] Video PyCon
On Wed, 13 Jan 2010 13:28:52 +0100, Luca Bacchi wrote: > È possibile scaricare i filmati dei vari anni nel formato originale? > Sono disponibili da qualche parte? Al momento sono disponibili i video del pycon1 e pycon2, quelli del pycon3 devono ancora essere caricati su viddler :( I video possono essere visionati in streaming da chiunque, se si vuole il formato originale si può scaricare da viddler previa registrazione sullo stesso. bye -- Mi contraddico, forse? Ebbene mi contraddico (sono vasto, contengo moltitudini) -- Walt Whitman ___ Python mailing list [email protected] http://lists.python.it/mailman/listinfo/python
