Re: [Python] Regole, cazziatoni, scazzi

[AlberTo De Prezzo]

Il 25/09/2014 09:30, Marco Beri ha scritto:
Quando devo dire a qualcuno che non sta seguendo le regole, glielo 
dico in privato. Rimanendo nella analogia della scorreggia, è come 
chiamare da parte la persona e dirgli "attento, qui dai fastidio 
quando scorreggi". Poi starà a lui farne cosa ne vuole 
dell'informazione e a me decidere di rispondere o meno se continua a 
scoraggiare. 


la comunicazione privata mi sembra il modo piu' costruttivo di 
comportarsi, quando si parla di mancato rispetto delle regole.
Quello che manca, a volte, è la tolleranza. Se Foo dice "io penso X", 
Bar invece dice "no! io penso Y", non è detto che qualcuno dei 2 abbia 
per forza torto o ragione (a patto che nessuno dei 2 fondi il suo 
pensiero su di un chiaro errore teorico/concettuale).
Potrebbe arrivare ad un certo punto Baz, leggere la discussione e trarre 
giovamento entrambi i punti di vista ed elaborarli autonomamente.


Qui lo dico e qui mi assumo il rischio di attrarmi le antipatie di 
chiunque:  talvolta si rischia di spaccare il capello in 4, in 8, in 
16... senza arrivare a nessuna conclusione. Il mondo è bello perchè è 
vario, e Foo puo' non essere d'accordo con Bar, puo' argomentarlo, ma 
sarebbe bello se lo facesse senza ostentare che *lui* ce l'ha piu' 
profumato di tutti.


Non è un attacco personale a te, Marco! anzi, sei uno di quelli che sa 
essere sempre molto attento a queste sfumature.


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

Re: [Python] (senza oggetto)

[AlberTo De Prezzo]

Il 24/09/2014 21:04, Filippo Dal Bosco - ha scritto:

# -*- coding: utf-8 -*-


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

Re: [Python] Algoritmo di ricerca per parole

[AlberTo De Prezzo]

Il 23/09/2014 18:40, AlberTo De Prezzo ha scritto:


  [...]in questo caso, il D che *risolve* sul G, mi fa capire che il G 
è il primo grado e G il quinto).




errata corrige: D è il quinto grado, G il primo

maledetta fretta :)

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

Re: [Python] Algoritmo di ricerca per parole

[AlberTo De Prezzo]

Il 23/09/2014 17:19, Simone Federici ha scritto:

Giuseppe Amato mailto:giuam...@gmail.com>>:

Il problema è che, ad esempio, l'accordo di Re maggiore contiene
l'alterazione in Fa#, pur non riportando alcun segno nell'accordo.
Nella pratica potrei avere una canzone con soli tre accordi Do Re
Sol in una tonalità di Sol maggiore e non accorgermene.




mi intrometto nuovamente :)
la discussione mi interessa molto perchè tempo fa, in ambito 
universitario, abbiamo sviluppato un software grazie al quale, per una 
partitura/tablatura (spesso di musica classica) si dovevano 
esaminare/elaborare alcuni aspetti, tra cui quello della tonalità.


Per quanto riguarda il tuo esempio, è vero che un'armonia del tipo

C-D-G

sembrerebbe non darci informazioni sulla tonalità, ma il mio 
suggerimento dato in precedenza di "fare riferimento" al ciclo delle 
quinte, vale anche per le triadi. Mi spiego meglio. Tutte le armonie, 
anche quelle così semplici, ci danno un'informazione fondamentale: la 
*cadenza* (in questo caso, il D che *risolve* sul G, mi fa capire che il 
G è il primo grado e G il quinto).


Per la mia esperienza, la ricerca delle *occorrenze* delle cadenze 
"quinto->primo" all'interno di un brano è il modo piu' economico ed 
affidabile per la determinazione della/e tonalità all'interno di una 
partitura.


my two cents

buona continuazione


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

Re: [Python] Algoritmo di ricerca per parole

[AlberTo De Prezzo]

Il 23/09/2014 15:17, Simone Federici ha scritto:


Fico!
parsing dei file alla ricerca degli accordi e poi individuazione della 
chiave. Diciamo che il problema sono i falsi positivi. Però per 
parecchie canzoni potrebbe funzionare contando le occorrente di un 
accordo e vedendo in che scala sta, poi con i parziali ai vincere la 
più probabile...




non potrebbe essere utile basarsi sul ciclo delle quinte [1] e 
verificare quali sono le alterazioni in chiave? Intendo dire:

1) parsing del file alla ricerca delle sigle degli accordi;
2) ricerca degli accordi alterati ;
3) confronto di tali accordi alterati con quelli del ciclo delle quinte.

Ad esempio, se in un brano trovo che gli accordi alterati sono Db e Gb, 
so che sono 2, quindi la scelta è presumibilmente fra Re maggiore e Sib 
Maggiore.
Per questi 2 accordi, faccio un controllo per verificare le "enarmonie": 
verifico cioè che tale coppia appartenga alla tonalità di Re maggiore, 
poichè le alterazioni appartengono alla combinazione degli accordi 
possibili per il Re maggiore:


1)C# e F#
2)Db e F#
3)Db e Gb <--- ## MATCH ##
4)C# e Gb

(L'unica struttura dati che devo preparare è tale sequenza di 
combinazioni di accordi possibili, per ogni tonalità).


In questo modo si coprirebbero con certezza tutte quelle canzoni in cui 
*non* ci sono accordi fuori dalla tonalità.


Spero di aver colto il nocciolo della questione

Saluti

[1]: http://www.studiarepianoforte.it/images/cicloquinte.gif
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] scannerino th tcp per divertirmi

[AlberTo De Prezzo]

Il 15/09/2014 19:56, Simone Federici ha scritto:

Nadir Sampaoli:

Personalmente mi sarei rallegrato di ricevere una chiara lista di
consigli come quelli di Dario che mi permettesse di migliorare.

see, l'informatica è buona proporzionalmente quanto veloce si 
implementa, una volta un saggio mi ha detto: "l' importante è che 
quello che fa e non come lo fa, anche se a calci" (cit.)




$grep coglionella /etc/brain_config | cut -d"=" -f2
enforcing

questo saggio lavorava alla Microsoft? :D





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

Re: [Python] Esclusione della query vuota

[AlberTo De Prezzo]

Il giorno 11 settembre 2014 12:47, Simone Federici 
ha scritto:

> Daniele Varrazzo :
>
>> Io propongo di darci un taglio e accettare che ci sono persone che hanno
>> obiettivi diversi dai vostri. Eccheccazzo, state a ricama' da stamattina,
>> sembrate delle vecchie in chiesa. Gli s'e' detto quello che gli si doveva
>> dire: direi che basta cosi' no? Ogni volta che c'e' una voce diversa dal
>> coro sembrate un branco di scimmie.
>
>
> hai ragione basta ricami...
>

non voglio fare la parte dell'avvocato(!!!) difensore di simone federici,
marco beri e degli altri (non ne hanno bisogno), ma vorrei spezzare una
*arancia* a loro favore: sappiamo tutti che le ML sono spesso utilizzate
per la ricerca di soluzioni anche da chi non è iscritto, e spesso è neofita
e magari anche frettoloso nella lettura. Far passare un messaggio
*sbagliato* è sempre da evitare, e percio' bene hanno fatto a sottolinearlo
con tripla matita blu.  don't try this at home!

saluti (e come dice mio zio.. vogliamoci bene)  :D
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Esclusione della query vuota

[AlberTo De Prezzo]

Il giorno 11 settembre 2014 12:28, Simone Federici 
ha scritto:

>
> propongo un ban immediato a tutti gli avvocati infiltrati in questa lista
>
>
e anche degli idraulici! :D
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [OT]: Laziness and co. [ERA]: Re: Range e float

[AlberTo De Prezzo]

Il giorno 10 settembre 2014 12:35, Nicola Larosa  ha
scritto:

> > AlberTo De Prezzo wrote:
> >> >>> criticare != offendere
> >> True
> >>
> >> in una lista come questa, IMHO non si dovrebbero usare questi toni.
>
> In quale lista invece si possono usare? ;-)
>
>
LOL
in pvt te ne posso dare almeno 4-5 in cui ti puoi sfogare alla grande.
Fìdati, è terapeutico..  :D

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

Re: [Python] [OT]: Laziness and co. [ERA]: Re: Range e float

[AlberTo De Prezzo]

Il giorno 10 settembre 2014 10:22, Nicola Larosa  ha
scritto:

> Lorenzo Sutton wrote:
> > http://threevirtues.com/
>
> Stai citando il progettista di Perl, cioè essenzialmente un imbecille.
>
>
>
>>>criticare != offendere
True

in una lista come questa, IMHO non si dovrebbero usare questi toni.
Larry Wall mi sembra tutto tranne che un imbecille, e per molti versi (da
vecchio programmatore Perl)
considero il suo linguaggio veramente geniale. E io non sarei stato capace
di scrivere un linguaggio
migliore del suo, quindi #RESPECT

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

Re: [Python] Range e float

[AlberTo De Prezzo]

Il giorno 10 settembre 2014 10:11, Carlos Catucci 
ha scritto:

>
> 2014-09-10 10:07 GMT+02:00 Marco Beri :
>
>> Però quando si tratta di quotare bene con uno smartphone, questa pigrizia
>> deve farsi da parte
>
>
> Quella non e' programmazione. Certo fare delle app di posta intelligenti
> sarebbe carino.
>
> Carlos
>

Il giorno 10 settembre 2014 11:12, AlberTo De Prezzo <
armit...@programmer.net> ha scritto:

> http://threevirtues.com/
>
> ipse dixit
>
>
>
ecco ... dimostrazione di quello capita *talvolta* anche a me: abituato con
evolution, ogni tanto vado di GMail,
ed ecco il  top quoting. sorry :)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Range e float

[AlberTo De Prezzo]

http://threevirtues.com/

ipse dixit

Il giorno 10 settembre 2014 10:11, Carlos Catucci 
ha scritto:

>
> 2014-09-10 10:07 GMT+02:00 Marco Beri :
>
>> Però quando si tratta di quotare bene con uno smartphone, questa pigrizia
>> deve farsi da parte
>
>
> Quella non e' programmazione. Certo fare delle app di posta intelligenti
> sarebbe carino.
>
> Carlos
> --
> EZLN ... Para Todos Todo ...
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Dizionario modificato.

[AlberTo De Prezzo]

Il giorno 05 settembre 2014 10:18, Walter Valenti 
ha scritto:

> Prendiamo questo semplice codice:
>
>
> def list():
> elem = dict()
> lista = []
> for x in range(3):
> elem['nome'] = x
> lista.append(elem)
> print lista
> list()
>
> Mi aspetterei come output:
> [{'nome': 0}, {'nome': 1}, {'nome': 2}]
> Quello che ottengo è invece:
> [{'nome': 2}, {'nome': 2}, {'nome': 2}]
>

imho quello che ti spiazza è il comportamento dell'append(), perchè ti
aspetti che all'interno del ciclo for,
l'append gestisca il *valore*, mentre in realta' gestisce le referenze. Mi
spiego meglio: quando usi l'append() tu
non fai altro che prendere una referenza al valore di elem ed assegnarla in
coda alla list lista.
Facendo in questo modo, ad ogni ciclo, al sovrascrivere del valore di elem,
variano tutte le sue referenze,
ed è per questo motivo che -a fine ciclo- ti ritrovi [{'nome': 2}, {'nome':
2}, {'nome': 2}], cioè il valore *finale* di elem, cui puntano
tutte le referenze appese in precedenza.

A tal proposito, guarda il comportamento del seguente codice:

def list():
elem = dict()
lista = []
for x in range(3):
    elem['nome'] = x
copia_shallow = elem.copy()
lista.append(copia_shallow)
print(lista)
list()

risultato:
[{'nome': 0}, {'nome': 1}, {'nome': 2}]

ciao
Alberto De Prezzo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Fwd: Digest di Python, Volume 101, Numero 36

[Alberto De Prezzo]

*> http://lists.python.it/mailman/listinfo/python>> ha scritto:*
>Non e' detto che fossero buoni esempi pero'.

e invece sono *buoni* esempi, certo forse sono pochi e/o poco
argomentati. Ma santiddio,
sono fatti per sostenere che con Java, anche quando devi gestire
situazioni banali, lo puoi fare
solo in maniera farraginosa. Guarda un po', con molti altri linguaggi,
persino con C#, strutture dati/sintassi/logica/architettura
sono molto piu' lineari. Certo, ogni linguaggio ha difetti e debolezze.
Ma questa è la mia modesta idea personale.


>Vedi, il problema non e' che solo perche' qualcuno abbia un'opinione,
>quell'opinione debba essere fondata.

allora, mettiamo in chiaro alcuni aspetti:

1) mi piacerebbe che tu usassi un tono meno arrogante.
2) stiamo discutendo del *nulla*. La mia opinione contro la tua. Chissenefrega?
3) le mie opinioni sono basate su qualche annetto di studio, e come
hai visto, non
vogliono essere *dogmi*. Puoi essere libero di non condividerle, e
persino di ignorarle.
4) spero che questa discussione stucchevole finisca senza ulteriori
lezioni su cosa è buono e
cosa non lo è.

P.S.: mi scuso se ci sono problemi di formattazione della mail, s'è
scocciato anche il mio client.

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

Re: [Python] Fwd: Digest di Python, Volume 101, Numero 36

[Alberto De Prezzo]

2014-07-27 19:48 GMT+02:00 enrico franchi :

>
>  Se e' complicato distinguere fra un TreeSet e un HashSet, lo e' perche'
> l'informatica e' complicata, non perche' Java e' complicata.
>


chi ha mai detto che è complicato *distinguere*? è semplicissimo. Come
l'informatica. Basta saper studiare e documentarsi.
Io ho detto altro e -perdonami- non lo ripeto per l'ennesima volta.
Ho espresso un parere su alcuni aspetti tecnici, avrei potuto fare altri
esempi, come ad esempio che non sono d'accordo sul fatto che con TreeSet si
usi compareTo(), mentre in HashSet -per lo stesso scopo- si usi equals(),
etc etc ... Gli esempi sono stati funzionali ad esprimere un mio parere,
cioè che Java tenda a sfuggire di mano, piu' di molti altri linguaggi. Se
facciamo un sodaggio sulle cose che si *odiano* piu' di Java, sono convinto
che ognuno abbia una sua lista, fattene una ragione.


> Cambia il fatto che la *piattaforma* e' tutta diversa. Quella roba ti
> parla *solo* del linguaggio, e' una roba un po' diversa. In realta' e' un
> pizzico piu' complicato di cosi', ma direi che non e' il caso di scendere
> nei dettagli. La piattaforma su cui esegui, sempre un'aktra e'.
>
>
Stai precisando l'ovvio. E' quello che ho detto anche io almeno *due*
volte. Il discorso è partito da kivy, per andare su android e quindi -per
estensione, visto che siamo su una ML Python- su Java (e relativa
piattaforma!). Puoi anche non essere d'accordo con il filo logico seguito,
ma così è.


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

Re: [Python] Fwd: Digest di Python, Volume 101, Numero 36

[Alberto De Prezzo]

2014-07-23 17:33 GMT+02:00 enrico franchi :

>
> 2014-07-23 11:24 GMT+02:00 enrico franchi :
>>
>>> In realta' la parte "collections" di Java e' veramente ben fatta e offre
>>> strumenti discretamente potenti e interessanti. Se poi uno non sa valutare
>>> pro e contro di array contro linked lists, verosimilmente scrivera' codice
>>> piuttosto pessimo
>>>
>>
>> questo concetto mi piace molto
>>
>
> In che senso?
>
>
nel senso che sono d'accordo. :)



>
> mi limitavo a constatare che i casi specifici da te portati non sono
> quelli che io vedo come esemplari dei problemi di Java (anzi, tutto sommato
> io li trovo dei casi piuttosto ben riusciti).
>

questione di punti di vista, io ho un'idea formata in anni di smadonnamenti
e non mi va di convincere nessuno-su-niente. IMHO le Collections in Java
sono un esempio qualsiasi per argomentare il fatto che la potenza di Java
spesso è *complicata*, e se posso, scelgo la *complessità*.


>
>> Il mio discorso era -inizialmente- collegato ad Android, e pertanto
>> relativo a Java SE*, e quindi non solo come linguaggio ma come piattaforma
>> (che include JVM, base libraries, lang/utils, Integration, UI Toolkits,
>> Deployment -webstart/Applet/plugin- e API/Tools vari).
>>
>
> Se fosse stato collegato ad Android, non avresti dovuto parlare
> minimamente di Java SE... JVM la ho tirata fuori io perche' stavo
> de-contestualizzando da Android.
>
>

Nello sviluppo in Android usi un *Language Level* di riferimento, quindi
non capisco questo tuo appunto.

http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Using-sourceCompatibility-1.7


Credo di essere stato chiaro sul rapporto Java/Android: in un certo qual
modo Android è in *relazione* alla versione di Java di riferimento. Tutto
qui.

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

Re: [Python] Fwd: Digest di Python, Volume 101, Numero 36

[Alberto De Prezzo]

2014-07-23 11:24 GMT+02:00 enrico franchi :

> In realta' la parte "collections" di Java e' veramente ben fatta e offre
> strumenti discretamente potenti e interessanti. Se poi uno non sa valutare
> pro e contro di array contro linked lists, verosimilmente scrivera' codice
> piuttosto pessimo
>

questo concetto mi piace molto


E anche il GC, *personalmente* non mi sembra che abbia nulla che non vada.
> E per inciso, pare essere piuttosto allo stato dell'arte di quei cosi li.
>

Anche su questo ci troviamo in sintonia. Non va neanche a me di andare OT
ed entrare nel merito dei singoli aspetti. Ma confermo solamente una cosa:
Java è potente, ma prolisso e contorto, e questi sono difetti non da poco,
ad oggi per *me* sono *la* discriminante per la scelta di
linguaggi/ambienti/tecnologie.

Tra l'altro, quella e' parte della JVM piu' che di Java in se e per se, in
effetti. E sebbene si possa dire ogni cosa di male su Java, la JVM resta
veramente un bel pezzo di software.


Tra l'altro, quella e' parte della JVM piu' che di Java in se e per se, in
> effetti. E sebbene si possa dire ogni cosa di male su Java, la JVM resta
> veramente un bel pezzo di software.
>

Il mio discorso era -inizialmente- collegato ad Android, e pertanto
relativo a Java SE*, e quindi non solo come linguaggio ma come piattaforma
(che include JVM, base libraries, lang/utils, Integration, UI Toolkits,
Deployment -webstart/Applet/plugin- e API/Tools vari). Chi non vi
riconoscere una potenza senza uguali (aka: *sono dei bei pezzi di software*),
non sa di che si sta parlando. Ma il prezzo che si deve pagare è troppo
alto, ed a meno che non si lavora in progetti per cui SE/EE sono una scelta
obbligata, IMHO si dovrebbe cercare di starne alla larga, se si ha un
minimo di amor proprio :)


(*)Non parliamo di EE altrimenti non ne usciamo piu'
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Fwd: Digest di Python, Volume 101, Numero 36

[Alberto De Prezzo]

2014-07-22 23:35 GMT+02:00 Marco Beri :

> Il 22/lug/2014 23:32 "Davide Crivello"  ha scritto:
>
> >
> > Non mi convince molto kivy. Passo a java
>
> Condoglianze.
>
> Ciao.
> Marco.
>
+1K

Non è il caso di far partire il flame, troppo semplice sparare su Java, che
IMHO ha *un* solo grande difetto, da cui a cascata derivano tutti gli
altri: tende ad essere contorto, in ogni suo aspetto, e quindi ogni scelta
rischia di sfuggire di mano. Vogliamo parlare ad es. della scelta fra
TreeSet, HashSet, ArrayList, LinkedList...? oppure degli "Iteratori"? o
parliamo di come tutto questo renda il GC un incubo peggio della peperonata
alle 3 di notte? (mi fermo qui)

E comunque, nel tuo caso, potrei pure accettare che tu scriva qui di optare
per Java/Android, a patto che dica "ho studiato bene l'architettura di
Kivy, ho provato, ho sbattuto la testa ma ho riscontrato i problemi x, y,
z". Purtroppo pero' temo che ti sia fermato alla terza riga di
documentazione. Non saresti il primo che con i vari bundle
bimbominkia-proof  per Android (es. Studio -appena uscito-) hai avuto
subito l'impressione di essere operativo. Ma basta andare oltre una
semplice Activity, oppure complicare *leggermente* Layout/View che si perde
il controllo di cosa succeda sotto.
Sbaglio?

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

Re: [Python] Python Android

[Alberto De Prezzo]

2014-07-21 16:14 GMT+02:00 Strap :

> > Salve a tutti, Ho capito che si possono fare degli script, aprirli con
> sl4a
> o con python for Android, ma non ho capito se si può sviluppare un app
> Android
> in python, creando un Apk che possa vivere senza che gli utenti debbano
> andare
> a scaricare dal play Store altre dipendenze.
> >
> > E se si, come? Ci sono guide? Spero che mi venite incontro, cia
> > Davide
> >
> >
>
> Oltre a kivy, dove trovi documentazione e anche un paio di libri, puoi
> valutare se http://qpython.com/ fa al caso tuo.
>
>
Kivy e Qpython sono 2 cose diverse, complementari.
QPython è uno script engine che wrappa interprete e SL4A.
Kivy è un low-high level framework, non-full stack, dipendente da svariate
librerie python (a seconda della piattaforma in cui è utilizzato).
Puoi creare e distribuire kivy-applications, cross platform, con un semplice

import kivykivy.require('x.y.z') # kivy version
from kivy.app import Appfrom kivy.uix.label import Label

class MyApp(App):

def build(self):
return Label(text='demo')

if __name__ == '__main__':
MyApp().run()


Da qui, (se vuoi) puoi decidere di generare un .apk.
http://kivy.org/docs/guide/packaging-android.html

Il progetto è fantastico, ma non credo di fare un torto a  nessuno se dico
che ancora ci sono alcuni problemi, soprattutto legati alle prestazioni.

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

Re: [Python] Lettere greche nel codice

[Alberto De Prezzo]

Il giorno 18 luglio 2014 13:01, Marco Beri  ha scritto:

>
>
> No compose key? Hai hai hai...
>
> Ciao.
> Marco.
>
> +1

se sei su linux, ti suggerisco:
$man compose

vedrai che la man page ti rimanda al file:
/usr/share/X11/locale//Compose

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

Re: [Python] Python 2.7 & 3 - afraid and terrified (?)

[Alberto De Prezzo]

Il giorno 13 luglio 2014 23:10, Dario Bertini  ha
scritto:

> il problema più grosso è lo split fra bytes e unicode
>
>
Lungi da me fare il difensore del BDFL, ma la smoother transition che state
ipotizzando ed argomentando, *credo* che alla fine della fiera non possa
essere fatta meglio di come sta avvenendo.
Quello che intendo io è che ci sono troppi punti di rottura con l'avvento
della 3, e non si tratta -solo- di sintassi e sottigliezze.
Sappiamo tutti che Python è molto cambiato, e sottovoce dico che è stato
molto migliorato e che per molti aspetti, se non avesse armonizzato tutti
questi aspetti, non so che futuro avrebbe avuto. IMHO, creare una versione
che faccia da ponte, andrebbe a creare molti piu' svantaggi che altro,
perchè in tale Python 2.8 dovrebbe convivere tutto (ed il contrario di
tutto).
Per gli aspetti per cui è possibile scrivere codice *python3 ready*, è già
a disposizione il builtin __future__, per la gestione di features e
keywords mandatory.  E' vero, per alcuni aspetti ci sarebbero pochi
problemi. Ad esempio, con il *raise* degli errori, che con  Py2 poteva
avvenire in 2 modi:
>>>raise TypeError, "errore xxx"
>>>raise TypeError("errore xxx")
e con py3 solo con la seconda forma: no-problem, si permettono ambedue le
sintassi ed il problema è risolto.
Così come le eccezioni ora non possono piu' essere lanciate con
>>>except ValueError, my_err
ma
>>>except ValueError(my_err)
anche qui non sarebbe un problema permettere ambedue le sintassi.
Anche print vs. print() è  una modifica sintattica, gestibile in una
ipotetica 2.8.
Anche se c'è da notare che in python 2 il seguente codice è sintatticamente
valido, ma restituisce una tupla.
>>>print('foo','bar').
Ma non è sempre così agevole il discorso. Ci sono cose nella 2.7 che non
sono accettabili:
La gestione degli operatori di divisione degli interi in python 2 è
abbastanza incomprensibile.
Unicode: Molto più pulito avere finalmente utf-8 *nativo*, ed a
disposizione byte (e bytearray). Basta con questi str() e unicode() da
wrappare assieme.
Sulle iterazioni, range soppianta e migliora xrange. E il __contains__, non
presente nella 2, rende impossibile l'utilizzo del costrutto "x in in
[x]range(foo)".
Alcuni comportamenti non-lineari nella gestione del namespace sono stati
eliminati. Il namespace globale è sempre isolato dai loop for e
comphrension varie. Niente piu' anomalie nel global namespace dopo le
iterazioni. wow.
Senza entrare troppo nello specifico di iteratori/iterabili/ __next__ e
__iter__, anche qui dico una sola cosa: ci basta solo il next(), niente più
metodo  obj.next(). E niente piu' scelta fra input() e raw_input(). C'è
solo input() che gestisce . amen.
Niente piu' stranezze sulla comparazione di tipi differenti
>>('foo','bar') > 'baz'
True # WTF???
IMHO è stata razionalizzata e potenziata anche la gestione degli iterabili.
Spesso non si ha un ret val  ma  (zip(), map(),
dict.keys(),...). Ora c'è semplicemente la possibilità di conversione in
list() a seconda delle necessità di iterazione, a seconda se c'è esigenza
di prestazioni/efficienza o persistenza (1-time-loop vs. n-time-loop).

E via discorrendo. Questi sono i primi punti che mi sono venuti in mente,
sono convinto che ce ne sono molti altri. Anche se mi sto accorgendo di
andare abbastanza controcorrente rispetto al pensiero diffuso in questa ML,
ripeto: IMHO è difficile fare transizioni morbide, quando si deve cambiare
e migliorare così tante cose. In una ipotetica 2.8 immagino codice zeppo di
"if python_version()" o "try/except" per gestire un marasma del genere,
ergo nello Zen andrebbero quindi cancellati:
Beautiful is better than ugly.
Readability counts.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Now is better than never.
Although never is often better than *right* now.



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

Re: [Python] Python 2.7 & 3 - afraid and terrified (?)

[Alberto De Prezzo]

Il giorno 12 luglio 2014 20:28, Giampaolo Rodola'  ha
scritto:

> Come può un'azienda fare una scelta tanto rischiosa? Semplice: non la fa.
>

Esatto. E Java, C# (.NET), Go & friends intanto ringraziano e vanno avanti
(dritti, o quasi)


> Un *vero* campione statistico riguardo il successo di Python 3 IMO si
> potrebbe avere solamente nel momento in cui chiunque può effetturare il
> porting senza porsi il problema se la libreria X o Y è stata portata o
> meno, e calcolare le tempistiche da allora (altro che da Python 3.0).
>


ti rispondo con due citazioni:


   -  "I am actually pretty optimistic. Lots of popular libraries have a
   working port or are working on one. (The Python Software Foundation also
   occasionally funds projects to port libraries that are widely used but
   don't have enough of a community to do a port.) It will take a long time,
   but I see a lot of progress, and in a few years I expect most new code will
   be written in Python 3. Totally eradicating Python 2 usage will probably
   take much longer, but then again, Windows XP isn't quite dead yet either.
   :-)" [1]
   




   - così è (se vi pare) [2]
   

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

Re: [Python] La matrice immortale.

[Alberto De Prezzo]

2014-07-09 11:10 GMT+02:00 Giovanni Porcari :

>
>  Gabriele non ti conosco  ma da quello che scrivi ti
>> stimo infinitamente :)
>>
>
>
> quoto
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Python 2.7 & 3 - afraid and terrified (?)

[Alberto De Prezzo]

Il giorno 08 luglio 2014 22:48, Dario Bertini  ha
scritto:

>
> Ma le soluzioni sono 3:
> - rimarrete per sempre con una codebase legacy Python2, con
> vulnerabilità di sicurezza non più fixate, ma che non importeranno
> perchè tanto andrete a proxare/wrappare tutte le interfacce di questo
> software con il mondo esterno (diciamo che diventerà tipo un Cobol...
> e questa è una cosa che avverà comunque in un sottinsieme ristretto di
> casi)
> - vi rimboccate le maniche assieme ad altre persone disposte a creare
> un Python2.8, col quale poter prolungare la vita un altro po' a
> Python2 (che già sarà comunque longevissimo), per poi finire nelle
> soluzioni 1 o 3
> - migrate a Py3 non appena tutte le piccole asperità verranno limate via
>


a compendio di quanto detto, vorrei proporre 3 link, che IMHO rappresentano
lo stato dell'arte sulla questione:

1) wall of superpowers:
http://python3wos.appspot.com/

2)il PEP-0404:
https://plus.google.com/115212051037621986145/posts/Pyj7PBEgwQ7

3) un'immagine da PyCon 2014:
https://pbs.twimg.com/media/BlG07oPCcAAdPJ5.png

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

[Python] Python 2.7 & 3 - afraid and terrified (?)

[Alberto De Prezzo]

Ascoltando quanto detto

da Kenneth Reitz  poco tempo fa, sono
rimasto colpito dai 2 termini usati: si definisce preoccupato, addirittura
*terrorizzato* dai numeri ancora troppo *a favore* di Python 2.x.  Ciò è
causa di dispersione di forze e frammentazione.

La mia curiosità è la seguente: quotidianamente, i partecipanti a questa
ML, con che versione si trovano a lavorare maggiormente? Quanti, oggi,
dovendo iniziare un progetto, utilizzano ancora la 2? Perchè? Per la mia
esperienza personale -ad esempio- posso affermare che io ed i miei
collaboratori ci  troviamo ad affrontare ~90% codice 3.x, facendo
praticamente sempre il porting di tutte le librerie non ancora disponibili.
Se posso scegliere/decidere io, non ho dubbi: i vantaggi della 3 sono
superiori. Voi?

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

Re: [Python] ANN: Disponibile Sandbox Genropy

[Alberto De Prezzo]

> Poi se vi piace datemi feedback, perchè scrivere un buon tutorial
> con il livello di dettaglio sufficiente è un lavoraccio e sapere
> di avere qualche lettore è una bella consolazione :).
>
>
Conosco il progetto da qualche anno: complimenti per il lavoro e la
dedizione dimostrata. Sono convinto che il progetto ha un potenziale ancora
inespresso. IMHO con una comunità più numerosa potrebbe dare grandi
soddisfazioni .
Una domanda: esiste una roadmap per il porting a Python 3?

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

Re: [Python] La matrice immortale.

[Alberto de prezzo]

Il giorno 02 luglio 2014 11:10, Gabriele Battaglia  ha
scritto:

>
> Per leggere i libri cartacei devo passarli, pagina per pagina, sullo
> scanner, poi applicare un processo di OCR e, ottenuto un testo editabile,
> correggere qua e là, dove serve, usando il cartaceo come riferimento, cosa
> che spesso richiede l'aiuto di un vedente. Se il testo è un romanzo, l'OCR
> fa un buon lavoro, a volte con una percentuale d'errore media davvero
> impressionante, 1% o -, ma se il testo ha tabella, indentazioni, grafici,
> simboli, tabelle, codici, diventa un disastro assoluto.
>
> Gabry.
>

La tua determinazione è un esempio per chi, spesso, dà troppe cose per
scontate, o si ferma al primo piccolo ostacolo che incontra. Perciò credo
che siamo noi che dobbiamo ringraziare te.


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

Re: [Python] La matrice immortale.

[Alberto de prezzo]

Il giorno 01 luglio 2014 18:15, Giovanni Porcari <
giovanni.porc...@softwell.it> ha scritto:

>
> > Il giorno 01/lug/2014, alle ore 15:37, Gabriele Battaglia <
> iz4...@libero.it> ha scritto:
> >
> > Ciao Giovanni e grazie.
> > Visto che in questi giorni, data la mia presenza, questa lista è
> diventata un asilo per programmatori... Dove l'infante sono io,
> chiaramente, mi spiegheresti il significato di questa riga?
> >
> > if __name__=='__main__':
>
>
>

Parti da un concetto: il filename di un modulo è disponibile nella
variabile global "__name__".
Giusto per capirci, tale "name" è quello che usi per importare un modulo:

>>>import mio_modulo
>>>mio_modulo.__name__
'mio_modulo'

Nota che il modulo è eseguito nel *suo* namespace. Considera il namespace
come semplicemente uno "spazio" in cui due moduli possono avere lo stesso
metodo fai_qualcosa(), senza che ci sia confusione tra i due.

Quando esegui invece il modulo da , prompt oppure come script, lo
fai invece nello spazio di nomi "globale", cioè
appunto nello spazio "main". All'atto pratico, la riga di codice in
questione (if  __name__ == '__main__') controlla proprio questo aspetto,
cioè lo spazio in cui "vive" il codice, ed evita che sia eseguito nel caso
in cui tale modulo è solamente importato.

Spero di essere stato chiaro.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Ide?

[Alberto de prezzo]

Il giorno 30 maggio 2014 09:08, Nicola Gramola 
ha scritto:

>
> Il 23/05/2014 15:42, Luigi Fontana ha scritto:
>
>>
>> Salve ho provato ninja-ide e mi ci sono trovato veramente bene. Solo che
>> su ubuntu ha lo spiacevole difetto di impallarsi spesso.
>>
>> Ci sono programmi alternativi validi? Con l'idle "ufficiale" a due
>> finestre non mi sento proprio a mio agio.
>>
>>

puoi provare anche pydev (http://pydev.org/)


just my tuppence worth
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Python for Ipad

[Alberto de prezzo]

Questo vuole le istruzioni per rendere native su ipad le applicazioni di
> python. Ovvero creare delle app clicckabili. E per qualche motivo è
> convinto che ci sia un'applicazione che lo faccia in automatico.
>
> Non esiste.
>
> Se si hanno queste esigenze e se (immagino) non si stia cercando di
> produrre software complicati ma solo giochini conviene veramente passare a
> java7.
>
> Inutile usare una ferrari per arare un campo.
>

Attenzione, se parliamo di iQualcosa, non serve Java ma Objective-C
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Dio prima li fa e poi ...

[Alberto de prezzo]

Il giorno 29 marzo 2014 09:14, Carlos Catucci  ha
scritto:

>
> E' che io mi sono accorto nel tempo che il frutto non cade mai lontano
> dall'albero.
> Se il papa di uno dei due progetti e' diventato quello che era Access per
> gli hobbisti dell'informatica (sono quindi  hobBITs?) per gli attuali
> hobbisti del " ... sito web fatto da mio cuggino che e' tanto bravo con il
> computer", anche se esteso su larga scala (mi chiedo ancora, esistono
> appositamente per il Big Data fior di db NoSql ma anche YesSql, che senso
> ha cercare di fare una versione di un Db pensato per carichi medio-piccoli
> adattata a qualcosa per cui non e' stato progettato all'inizio? Non si
> rischia forse una serie di pezze a colore che rendereanno poi il progetto
> inusabile? Se io mi accorgo di avere sbagliato un progetto butto il
> superfluo, tengo le poche cose (se ci sono) valide e riscrivo dopo avere
> riprogettato) che possono svolgere bene quel lavoro.
>


Concordo con il *mitico* Carlos, però IMHO stai ragionando una/due mosse
avanti. Intendiamoci, è molto probabile che alla fine vada come dici tu, ma
invito a ragionare senza pregiudizievoli. Chi ha un po' di esperienza, sa
che molti progetti validi sono nati da progetti non all'altezza, e
viceversa :)

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

Re: [Python] Usare il db giusto, non quello sbagliato

[Alberto De Prezzo]

Il 12/07/2013 17:00, python-requ...@lists.python.it ha scritto:
> Si dice "plonk".
>
> *plonk*
DNFT
/
click.
/
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Usare il db giusto, non quello sbagliato

[Alberto De Prezzo]

Il 11/07/2013 21:29, python-requ...@lists.python.it ha scritto:
> 2013/7/11 Enrico Bianchi 
>
>> > Qua ti posso rispondere io. Query complessa con un fottiliardo di inner
>> > join del tipo "WHERE t1.campo = t2.campo" in mezzo, non modificabile
>> > perche` generata da un simil orm. Su MySQL (5.1 se non ricordo male, ma e`
>> > un problema anche in 5.5), su macchina virutale pompata linux 64bit, il
>> > database ci metteva un'ora per tirare fuori i dati. Su Oracle 11g, su
>> > macchina fisica pompata linux 64bit, ci metteva 5 minuti. Su PostgreSQL
>> > (una 9.0 o una 9.1, non ricordo), su macchina virutale windows (2003 32bit,
>> > 1 core e 512Mb di RAM allocati) ci ha messo 7 minuti
> Come benchmark non male. E dimostra come non stiamo dicendo cazzate.
>
> Carlos
> -- 
Ah be, se questo è il tenore della discussione, neanche mi ci metto a
documentare le mie affermazioni.
Avete ragione: Postgres lo usano i professionisti, Mysql i wannabe:
quelli di *google* sono tutti dei pirla,
quelli di *facebook* e *twitter* poi non ne parliamo. *VMware* ? dei
perditempo.
*AT&T* poi, lo fanno solo per questioni di legacy. *Cisco*? bleah.
*Ericsson*? devono andare a raccogliere il basilico.
 *Nokia*? sono 4 gatti, chi se ne frega. *Lufthansa*? mai sentiti.
*Paypal*? ma va là, non capiscono niente. Come quelli di
*Yahoo*! ah,*Youtube* poi, gestisce 4 video messi in croce...

ce ne sono altre centinaia di sfigati, ma chi se ne frega, quelli in
gamba sono su questa lista.

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

[Python] R: Digest di Python, Volume 89, Numero 26

[Alberto de Prezzo]

python-requ...@lists.python.it ha scritto:

Invia le richieste di iscrizione alla lista Python all'indirizzo
python@lists.python.it

Per iscriverti o cancellarti attraverso il web, visita
http://lists.python.it/mailman/listinfo/python
oppure, via email, manda un messaggio con oggetto `help' all'indirizzo
python-requ...@lists.python.it

Puoi contattare la persona che gestisce la lista all'indirizzo
python-ow...@lists.python.it

Se rispondi a questo messaggio, per favore edita la linea dell'oggetto
in modo che sia più utile di un semplice "Re: Contenuti del digest
della lista Python..."


Argomenti del Giorno:

   1. Re: Usare il db giusto, non quello sbagliato (Marco Beri)
   2. Re: Usare il db giusto, non quello sbagliato (Carlos Catucci)
   3. Re: Usare il db giusto, non quello sbagliato (Carlos Catucci)
   4. Re: Usare il db giusto, non quello sbagliato (Enrico Bianchi)
   5. Re: Usare il db giusto, non quello sbagliato (Carlos Catucci)
   6. Re: Usare il db giusto, non quello sbagliato (Enrico Bianchi)
   7. Re: Usare il db giusto, non quello sbagliato (Carlos Catucci)


--

Message: 1
Date: Thu, 11 Jul 2013 21:20:09 +0200
From: Marco Beri 
To: Discussioni generali sul linguaggio Python

Subject: Re: [Python] Usare il db giusto, non quello sbagliato
Message-ID:

Content-Type: text/plain; charset="utf-8"

2013/7/11 Marco Beri 

> Credo tu sia passabile di non so quale richiesta di risarcimento.
>

Ehm... passibilie... :-)
-- parte successiva --
Un allegato HTML è stato rimosso...
URL: 


--

Message: 2
Date: Thu, 11 Jul 2013 14:52:56 -0430
From: Carlos Catucci 
To: Discussioni generali sul linguaggio Python

Subject: Re: [Python] Usare il db giusto, non quello sbagliato
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

2013/7/11 Andrea Francia 

> Penso per lo stesso motivo per cui in Facebook usano PHP.
>>
> ... perché così possono usare phpMyAdmin!
>

+1 LOL


-- 
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." -  Ernesto Guevara de la Serna
Lynch
-- parte successiva --
Un allegato HTML è stato rimosso...
URL: 


--

Message: 3
Date: Thu, 11 Jul 2013 14:54:12 -0430
From: Carlos Catucci 
To: Discussioni generali sul linguaggio Python

Subject: Re: [Python] Usare il db giusto, non quello sbagliato
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

2013/7/11 Enrico Bianchi 

> Anche lui mi sta deludendo parecchio, almeno lato amministrativo. Oggi,
> dopo due ore, mongodump era ancora al 1% per dumpare una collezione di
> 17mln di record. Cercando in giro informazioni in merito, tutti entravano
> in modalita` supercazzola, dando la colpa ai dischi o, in generale, alla
> macchina, tanto che i workaround piu` gettonati erano fsync + snapshot lvm
> oppure start replica, stop replica, backup replica. Per ora il mio giudizio
> rimane ancora in modalita` meh, vedremo come matura


Non ho ancora fatto mai un dump ma essendo testuale una compressione
brutale no? Tipo un tar.gz del file ? Chiedo da ignorante, non ho ancora
abbastanza esperienza sui backup di Mongo.

Carlos
-- 
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." -  Ernesto Guevara de la Serna
Lynch
-- parte successiva --
Un allegato HTML è stato rimosso...
URL: 


--

Message: 4
Date: Thu, 11 Jul 2013 21:28:10 +0200
From: Enrico Bianchi 
To: Discussioni generali sul linguaggio Python

Subject: Re: [Python] Usare il db giusto, non quello sbagliato
Message-ID: <51df074a.3020...@ymail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 07/11/2013 09:13 PM, Andrea Francia wrote:
> 1) Ma questi problemi di MySQL di cui parlate si riferiscono solo alle 
> prestazioni o c'e' altro, tipo affidabilità, strutture dati supportati?
Entrambi. Il planner di MySQL e` parecchio sensibile a come scrivi la 
query, o meglio se non la scrivi come dice lui il planner scazza e di 
brutto (senza contare che lo fa sia in ordinamento che in caso di 
viste). Lato amministrativo, l'ultimo esempio l'ho avuto durante la 
conversione del db in UTF-8. Praticamente, dopo aver eseguito il dump 
testuale ed averlo convertito in UTF-8, al momento del restore, 
nonostente passassi al client l'opzione per inviare pacchetti di 32Mb al 
database, mi resettava la connessione senza un e

Re: [Python] Usare il db giusto, non quello sbagliato

[Alberto De Prezzo]

> Quali? Scusa Nicola ma io non vedo sostenitori di MySql se non tra i
> lamerazzi che fanno sitarelli in PHP (meglio ancora con Joomla o Wordpress
> (la moda del momento) usando magari un ide/editor Adobe a caso.
>
> Che Postgres sia non solo superiore (di brutto) a MySql, ma addirittura
> possa tranquillamente essere una valida alternativa a Oracle, non sono io
> ad affermarlo ma gente ben piu' in gamba di me.
>
> Se volevi scatenare un flame (vista 'estate fresca che stiamo avendo posso
> capire il perche') potevi scegliere argomenti tipo meglio Pyton2.x o
> Python3.x ;)
>
> Carlos

Non è la prima volta che in questa lista leggo interventi come
questo, e mi permetto di dire che sono
 *quantomeno* ingiusti, se non addirittura sbagliati e fuorvianti.

Premetto -molto modestamente- che, sia grazie agli studi
universitari, sia grazie a vari percorsi privati e di autodidatta,
conosco ed utilizzo svariati linguaggi, e cerco di tenermi quanto
più aggiornato possibile dedicando molto tempo,
ancora oggi, allo studio, compatibilmente alle esigenze lavorative.
Insomma, cerco di parlare con cognizione di causa.

IMHO ritengo che Mysql, PostgreSQL e Oracle siano completamente
differenti, e quindi che la scelta dipenda dal progetto che si sta
affrontando.
Non conosco personalmente/lavorativamente chi fa queste
affermazioni, ma mi sembra giusto portare
i miei "2 cents" a beneficio dei giovani che leggono:
nel 2013 non è il linguaggio o il database che si utilizza che fa di
te un "lamerozzo", ma *come* lo si sceglie,
*come* lo si configura e *come* si utilizza. Consigliare il cliente
e guidarlo in base alle sue priorità:
scalabilità, velocità di realizzo, costi di
sviluppo/gestione,ambiente di produzione,... chi se la sente di dire che
esiste una soluzione valida sempre?
Personalmente possiamo avere delle preferenze, e magari la nostra
attività lavorativa ci porta maggiormente a
fare delle scelte, ma sono soggettive e non generalizzabili.


Alberto





 



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

Re: [Python] R: Re: VIM code completion

[Alberto De Prezzo]

Il 17/01/2013 23:50, Marco Beri ha scritto:
>
> Alberto,
> secondo me l'hai presa male per nulla.
>
> Enrico è tutto meno che un "flammaro" e, soprattutto, non è uno che
> non sa di cosa sta parlando.
>
> Ciao.
> Marco.
>

Se mi viene contestato che pydiction è vecchio, dicendo di preferire
supertab, è evidente che non si sa bene di cosa si stia parlando:
pydiction - 2009-07-25, versione 7.0
supertab - 2006-07-11, versione 6.0

Fonti:
http://www.vim.org/scripts/script.php?script_id=182
http://www.vim.org/scripts/script.php?script_id=850

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

[Python] R: Re: VIM code completion

[alberto de prezzo]

--
Alberto De Prezzo
--

enrico franchi  ha scritto:



PyDiction e' vecchio quasi quanto spiegare che il top quoting e' male. 
Funzionare funziona, ma oggi c'e' di meglio: ovvero qualcosa che in generale, 
analizza i sorgenti e compila su quelli.

Io ho messo insieme un po' di roba, ma conviene partire da qui:

http://sontek.net/blog/detail/turning-vim-into-a-modern-python-ide 


-- 
.
..: -enrico- 

criticare il top posting su 2 righe di discussione mi ricorda i motivi per cui 
anni fa avevo smesso di seguire le mailing list dell'italietta fatta da tanta 
gente in gamba e da qualche frustrato che non vede l'ora di far partire i flame 
su minchiate tipo la superioritá delle risposte inline . . . non sapendo, 
evidentemente, neanche bene di cosa si stia parlando. Io sono il primo che si 
batte per il netiquette e livello delle discussioni, ma leggere risposte del 
genere mi fa passare la voglia .. piu' di leggere *sgrammaticature* e scazzi 
vari.

infine.. se pydiction è vecchio, di certo ha il vantaggio di una configurazione 
semplice e modulare, giusto per il code completion.. come richiesto dal nostro 
interlocutore. 
Io ho solo chiesto se l'ha provato. IMHO è un buon punto di partenza.

buon divertimento .. e complimentoni!!___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] VIM code completion

[Alberto De Prezzo]

hai provato il pydiction ?
http://www.vim.org/scripts/script.php?script_id=850

Il 17/01/2013 14:31, piergiorgio pancino ha scritto:
>
> Ciao a tutti,
> qualcuno di voi utilizza VIM come IDE per python?
> Io lo sto usando e vorrei implementare l'opzione di code completion,
> ho cercato di capire come fare, ma confesso che il procedimento non mi
> è sembrato molto semplice, per questo volevo chiedere se qualcuno di
> voi usa VIM e mi saprebbe dare qualche indicazione su come fare.
> Grazie
> Piergiorgio
>
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Documentazione

[Alberto De Prezzo]

e ora ti sei spiegato anche peggio ... ma perché tanta gente non rilegge
almeno una volta la *PROPRIA* domanda ?
ciclando? ho i moduli? funzione contenute?

e poi la punteggiatura, questa sconosciuta 

sono io di un altro pianeta?



Il 15/01/2013 15:18, Michele Gatti ha scritto:
> Ok mi sono spiegato male, io sto ciclando su tutta la python/lib e ho
> i moduli e vorrei trovare per ogni modulo la ducomentazione relativa
> alle classi e funzione contenute in esso
>
>
>  
>
> logo 
>   *Michele Gatti*
> /"Per imparare un nuovo linguaggio di programmazione ci vuole un sacco
> di lavoro, e le persone non imparano Python perché questo permetterà
> loro di avere un lavoro, ma perché amano genuinamente programmare e
> non sono soddisfatte con i linguaggi che già conoscono."/
>
> Flickr  LinkedIn
>  Tumblr
>  pinterest 
> Get a signature like this:
> 
> Click here!
> 
>
>
>
> Il giorno 15 gennaio 2013 15:10, Federico Frenguelli
> mailto:synas...@gmail.com>> ha scritto:
>
> Ciao
>
> puoi usare help() passando come argomento il modulo o la funzione
> di cui vuoi la documentazione
>
> Esempio
> >>> import re
> >>> help(re)
>
>
>
>
> Il giorno 15 gennaio 2013 15:05, Michele Gatti
> mailto:mgsoluzi...@gmail.com>> ha scritto:
>
> Ciao a tutti, avrei bisogno di recuperare la documentazione
> dei moduli della libreria standard di python a runtime
> Come posso fare?
>
>
> logo 
>   *Michele Gatti*
> /"Per imparare un nuovo linguaggio di programmazione ci vuole
> un sacco di lavoro, e le persone non imparano Python perché
> questo permetterà loro di avere un lavoro, ma perché amano
> genuinamente programmare e non sono soddisfatte con i
> linguaggi che già conoscono."/
>
> Flickr  LinkedIn
>  Tumblr
>  pinterest
> 
> Get a signature like this:
> 
> 
> Click here!
> 
> 
>
>
> ___
> Python mailing list
> Python@lists.python.it 
> http://lists.python.it/mailman/listinfo/python
>
>
>
>
> -- 
> Federico Frenguelli
>
> ___
> Python mailing list
> Python@lists.python.it 
> http://lists.python.it/mailman/listinfo/python
>
>
>
>
> -- 
>
> Michele Gatti
>
> MG Soluzioni Informatiche
>
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] R: Re: R: Re: Versione Python

[alberto de prezzo]

1) si, il beri e il lutz sono ottimi.
2) il programming python lo troverai solo presso chi distribuisce o reilly - 
tecniche nuove. ma prima studia bene i 2 testi di cui sopra
3) alternative a tkinter? imho stai andando troppo oltre. tkinter + magari pmw 
sono tanta roba. poi c'e' wxPython. di piu' alto livello poi c'e' Dabo. ma vai 
con calma, ora :-)



andrea terrone  ha scritto:

Ok grazie mille, le chiedo l'ultima cosa.
Siccome ho cominciato da qualche tempo ad usare python, vanno bene per 
cominciare i libri imparare python (di mark lutz) e python pocket (di marco 
beri) ? E poi il libro programming python (di mark lutz riguardante la versione 
python 3.x) lo potrò trovare in qualsiasi libreria e l'ultimissima cosa, oltre 
a tkinter per la grafica cosa posso usare per python? grazie per le risposte

Il giorno 30 agosto 2012 15:22, alberto de prezzo  
ha scritto:
certo. ma se puoi,meglio l'originale. nella traduzione ci sono un po' di 
refusi. e poi parole come "scriptare" non le tollero proprio

:-






andrea terrone  ha scritto:



Ecco ora vedo quello che ha scritto lei, ma ieri sera vedevo he la versione 
corrente era 3.1.2.  Ora avrei un ultima domanda, il libro in inglese 
programming python di mark lutz è stato tradotto in italiano o no?

Il giorno 30 agosto 2012 12:46, Carlo Miron  ha scritto:
2012/8/30 Marco Beri :
> 2012/8/30 andrea terrone 
>> Scusate per l'ignoranza, ma perché pochi giorni fa mi sono scaricato la
>> versione 3.2 di python ed ora trovo sul sito che l'ultima versione è la
>> 3.1.2?
>
> Leggo ora da http://python.org/download/ :
> The current production versions are Python 2.7.3 and Python 3.2.3.
> Di quale sito stai parlando?

Credo di python.it. Ora dovrebbe essere apposto, grazie all'OP per il reminder.

©
--
  R
K--S
  L
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python


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


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

[Python] R: Re: Versione Python

[alberto de prezzo]

certo. ma se puoi,meglio l'originale. nella traduzione ci sono un po' di 
refusi. e poi parole come "scriptare" non le tollero proprio

:-





andrea terrone  ha scritto:

Ecco ora vedo quello che ha scritto lei, ma ieri sera vedevo he la versione 
corrente era 3.1.2.  Ora avrei un ultima domanda, il libro in inglese 
programming python di mark lutz è stato tradotto in italiano o no?

Il giorno 30 agosto 2012 12:46, Carlo Miron  ha scritto:
2012/8/30 Marco Beri :
> 2012/8/30 andrea terrone 
>> Scusate per l'ignoranza, ma perché pochi giorni fa mi sono scaricato la
>> versione 3.2 di python ed ora trovo sul sito che l'ultima versione è la
>> 3.1.2?
>
> Leggo ora da http://python.org/download/ :
> The current production versions are Python 2.7.3 and Python 3.2.3.
> Di quale sito stai parlando?

Credo di python.it. Ora dovrebbe essere apposto, grazie all'OP per il reminder.

©
--
  R
K--S
  L
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

Re: [Python] Psycopg2 e il formato data

[Alberto De Prezzo]

da quello che dici, il problema dovrebbe essere semplicemente legato al
setting di DateStyle, su postgres

http://www.postgresql.org/docs/8.2/static/runtime-config-client.html#GUC-DATESTYLE



Il 24/08/2012 17:01, marco...@libero.it ha scritto:
> Ciao a tutti!
> Ho trovato delle mail in rete di Daniele Varrazzo, dove scrive che Psycopg2 
> NON riconosce che tipo di dato si va ad inserire in PostgreSQL.
> Ok.
> Vorrei però postare un quesito lo stesso.
> 
> Ho un server PostgreSQL che gira in ambiente Linux.
> Ci inserisco, tramite Psycopg, delle date in colonne con formato "date". Le 
> inserisco in formato stringa, così: "dd-mm-aa".
> Mai avuto problemi.
> 
> Ho installato un server PostgreSQL in un sistema Windows Server, e lì i 
> problemi sono nati. Posso inserire le date solo in formato "-mm-dd".
> Come mai secondo voi?
> 
> Grazie.
> 
> Marco
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python