Re: [Python] Il dilemma degli array mutabili

[Piergiuliano Bossi]

2013/9/19 Riccardo Lemmi 

> Piergiuliano Bossi wrote:
>
> > 2013/9/18 Riccardo Lemmi 
> >
> >>
> >>
> >> Mi sfugge il caso, forse un esempio chiarirebbe... L'unico posto in
> >> cui vedo male il codice messo sopra è quello in cui si usano gli
> >> elementi dell'array non in sequenza ma pescando in "qua e la'"
> >>
> >>
> > Ho visto la luce.
> >
> > Questo e' il codice che ha causato il thread (semplificato,
> > ovviamente);
> >
> > def evaluate(list):
> > return sum(v for v in list if v % 2 == 0)
> >
> > def _subtract(list1, list2):
> > result = list1[:]
> > for val in list2:
> > result.remove(val)
> > return result
>
> Manca un check prima di fare il remove. Alternativamente la scriverei
> così:
>
>
Vero, ma in questo contesto so gia' che l'elemento che rimuovo e' gia'
nella lista.


>
> detto così sembra proprio che tu stia lavorando con i set...
>
>
Quasi: in realta' ognuna di quelle liste puo' contenere duplicati, quindi i
set sono fuori discussione. Mi ero baloccato con l'idea di usare un dict
dove la chiave e' la posizione nella lista originaria, ma diventava tutto
troppo complesso e l'algoritmo e' insensibile rispetto alla posizione nella
lista.


Ciao
Giuliano



-- 
Piergiuliano Bossi
Blog: http://thinkingbox.wordpress.com/
Twitter: http://twitter.com/thinkingbox (English)
Twitter: http://twitter.com/scatolapensante (Italiano)
Google+: https://plus.google.com/u/0/108187981162465525118
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Giovanni Porcari]

Il giorno 19/set/2013, alle ore 16:31, Marco Beri  ha 
scritto:

> Il giorno 19/set/2013 15:08, "Piergiuliano Bossi"  ha 
> scritto:
> che fa tutto al volo e mi e' venuta al primo colpo:
> 
> > def useless(list):
> > return [list[i] for i in range(len(list)) if evaluate(list[:i] + 
> > list[i+1:]) == evaluate(list)]
> 
> Questo codice può diventare un più chiaro con enumerate:
> 
> def useless(list):
> return [val for i, val in enumerate(list) if evaluate(list[:i] + 
> list[i+1:]) == evaluate(list)]
> 
> 


Butto lì un'ipotesi vaga senza pensarci troppo (quindi ha un'elevata 
probabilità di essere una fesseria) :

E se invece di togliere gli elementi si usasse un array parallelo di booleani 
che dicono se l'elemento è attivo o no ?

Si potrebbe avere un generatore che dice

def filtered_list(mylist,flags):
for k,v in enumerate(mylist):
if flags[k]:
yield v


E poi la evaluate si fa sulla filtered_list.

A questo punto non si deve duplicare la lista ma solo settare i flag e ripetere 
il calcolo.

Dico una bestialità o ha un senso ?

G.

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

Re: [Python] Il dilemma degli array mutabili

[Diego Barrera]

Il 19/09/2013 16:31, Marco Beri ha scritto:


Il giorno 19/set/2013 15:08, "Piergiuliano Bossi" > ha scritto:

che fa tutto al volo e mi e' venuta al primo colpo:

> def useless(list):
> return [list[i] for i in range(len(list)) if evaluate(list[:i] + 
list[i+1:]) == evaluate(list)]


Questo codice può diventare un più chiaro con enumerate:

def useless(list):
return [val for i, val in enumerate(list) if evaluate(list[:i] + 
list[i+1:]) == evaluate(list)]



Pero' evaluate potrebbe essere complessa..

def useless(mylist):
k = evaluate(mylist)
return [val for i, val in enumerate(mylist) if evaluate(list[:i] + 
list[i+1] == k]


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

Re: [Python] Il dilemma degli array mutabili

[Riccardo Lemmi]

Piergiuliano Bossi wrote:

> 2013/9/18 Riccardo Lemmi 
> 
>>
>>
>> Mi sfugge il caso, forse un esempio chiarirebbe... L'unico posto in
>> cui vedo male il codice messo sopra è quello in cui si usano gli
>> elementi dell'array non in sequenza ma pescando in "qua e la'"
>>
>>
> Ho visto la luce.
> 
> Questo e' il codice che ha causato il thread (semplificato,
> ovviamente);
> 
> def evaluate(list):
> return sum(v for v in list if v % 2 == 0)
> 
> def _subtract(list1, list2):
> result = list1[:]
> for val in list2:
> result.remove(val)
> return result

Manca un check prima di fare il remove. Alternativamente la scriverei 
così:

def _subtract(list1, list2):
result = []
for val in list2:
if val not in list2:
 result.append(val)
return result

ma se non ci sono ridondanze nelle due liste cioè stai effettivamento 
implementando la differenza fra insiemi:

result = set(list1) - set(list2)

o

result = set(list1).difference(list2) 

> def useless(list):
> useful = list[:]
> for val in list:
> useful.remove(val)
> if evaluate(useful) != evaluate(list):
> useful.append(val)
> return _subtract(list, useful)
> 
> if __name__ == "__main__":
> print(useless([]))# => []
> print(useless([1, 2, 3, 5, 8]))# => [1, 3, 5]
> 
> Codice abbastanza orrido, no?
> 
> L'idea e' calcolare gli elementi di una lista che non contribuiscono
> al valore determinato da una certa funzione. Diciamo che evaluate in
> realta' e' molto piu' complessa (non computazionalmente, ma
> matematicamente non e' semplice), che e' insensibile all'ordine degli
> elementi nella lista (da cui l'uso di remove non posizionale) e che
> ovviamente questo codice non e' ottimizzato (eg: e' inutile chiamare
> evaluate(list) ogni volta nel ciclo).
> 

detto così sembra proprio che tu stia lavorando con i set...

> L'ho riscritto senza copy.copy ma con [:] e ovviamente tutto bene, ma
> non e' un gran guadagno. Poi ho provato a fare una comprehension che
> fa tutto al volo e mi e' venuta al primo colpo:
> 
> def useless(list):
> return [list[i] for i in range(len(list)) if evaluate(list[:i] +
> list[i+1:]) == evaluate(list)]
> 
> Oserei dire che e' persino un pelo piu' comunicativa cosi', visto che
> non devo calcolare una lista e poi sottrarla all'altra.
> Mi sento come se avessi trovato il barattolo di nutella di Moretti, un
> cucchiaione e nessuno attorno...  :)
> 
> Ciao
> Giuliano
> 
> PS: queste sono le cose che fanno scattare l'aore...
> 
> 

-- 
   Riccardo Lemmi

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

Re: [Python] Il dilemma degli array mutabili

[Piergiuliano Bossi]

On Thu, Sep 19, 2013 at 11:10 AM, Nicola Larosa  wrote:

> Meglio non usare "list" come nome, perchè copre il builtin.
>

Giusto, devo riprogrammarmi il cervello per le parole tabu'.

Ciao
Giuliano


-- 
Piergiuliano Bossi
Blog: http://thinkingbox.wordpress.com/
Twitter: http://twitter.com/thinkingbox (English)
Twitter: http://twitter.com/scatolapensante (Italiano)
Google+: https://plus.google.com/u/0/108187981162465525118
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Nicola Larosa]

> Piergiuliano Bossi ha scritto:
>> def useless(list):
>> return [list[i] for i in range(len(list)) if evaluate(list[:i] +
>> list[i+1:]) == evaluate(list)]

Marco Beri wrote:
> Questo codice può diventare un più chiaro con enumerate:
> 
> def useless(list):
> return [val for i, val in enumerate(list) if evaluate(list[:i] +
> list[i+1:]) == evaluate(list)]

Meglio non usare "list" come nome, perchè copre il builtin.

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

I'll play closed-source games because they're not very harmful, and
it doesn't bother me when I ride an elevator with closed-source
firmware, but I will not - ever, under any circumstances, for any
reason - give Apple my money or my approval so that it can lock more
people into its beautifully-decorated jails. - Eric Raymond, April 2013

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

Re: [Python] Il dilemma degli array mutabili

[Nicola Larosa]

> Piergiuliano Bossi ha scritto:
>> def useless(list):
>> return [list[i] for i in range(len(list)) if evaluate(list[:i] +
>> list[i+1:]) == evaluate(list)]

Marco Beri wrote:
> Questo codice può diventare un più chiaro con enumerate:
> 
> def useless(list):
> return [val for i, val in enumerate(list) if evaluate(list[:i] +
> list[i+1:]) == evaluate(list)]

Meglio non usare "list" come nome, perchè copre il builtin.

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

I'll play closed-source games because they're not very harmful, and
it doesn't bother me when I ride an elevator with closed-source
firmware, but I will not - ever, under any circumstances, for any
reason - give Apple my money or my approval so that it can lock more
people into its beautifully-decorated jails. - Eric Raymond, April 2013

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

Re: [Python] Il dilemma degli array mutabili

[Marco Beri]

2013/9/19 Piergiuliano Bossi 

> Mi sento come se avessi trovato il barattolo di nutella di Moretti, un
> cucchiaione e nessuno attorno...  :)
> Ciao
> Giuliano
> PS: queste sono le cose che fanno scattare l'aore...
>

Dimenticavo: :-)

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Piergiuliano Bossi]

On Thu, Sep 19, 2013 at 10:31 AM, Marco Beri  wrote:

> Il giorno 19/set/2013 15:08, "Piergiuliano Bossi"  ha
> scritto:
>
> che fa tutto al volo e mi e' venuta al primo colpo:
>
> > def useless(list):
> > return [list[i] for i in range(len(list)) if evaluate(list[:i] +
> list[i+1:]) == evaluate(list)]
>
> Questo codice può diventare un più chiaro con enumerate:
>
> def useless(list):
> return [val for i, val in enumerate(list) if evaluate(list[:i] +
> list[i+1:]) == evaluate(list)]
>
>
Eh si', concordo!

Grazie e ciao
Giuliano



-- 
Piergiuliano Bossi
Blog: http://thinkingbox.wordpress.com/
Twitter: http://twitter.com/thinkingbox (English)
Twitter: http://twitter.com/scatolapensante (Italiano)
Google+: https://plus.google.com/u/0/108187981162465525118
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Marco Beri]

Il giorno 19/set/2013 15:08, "Piergiuliano Bossi"  ha
scritto:
che fa tutto al volo e mi e' venuta al primo colpo:

> def useless(list):
> return [list[i] for i in range(len(list)) if evaluate(list[:i] +
list[i+1:]) == evaluate(list)]

Questo codice può diventare un più chiaro con enumerate:

def useless(list):
return [val for i, val in enumerate(list) if evaluate(list[:i] +
list[i+1:]) == evaluate(list)]

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

Re: [Python] Il dilemma degli array mutabili

[Marco Mariani]

Le list comprehension sono il male assoluto XD
Prova per confrontare, una versione con iter_useless() che fa uso di yield,
e al limite una def useless(): return list(iter_useless())
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Daniele Varrazzo]

On 2013-09-19 14:08, Piergiuliano Bossi wrote:


def useless(list):
return [list[i] for i in range(len(list)) if evaluate(list[:i] +
list[i+1:]) == evaluate(list)]

Oserei dire che e' persino un pelo piu' comunicativa cosi', visto che 
non

devo calcolare una lista e poi sottrarla all'altra.


Se questo codice ha bisogno di essere efficiente puoi anche 
implementarlo con collections.deque. Vedi la ricetta di delete_nth() 
negli esempi per un accenno a come fare.


Se non deve essere efficiente (cosa che potrebbe essere, visto che 
calcoli evaluate(list) per len(list) volte quando ne basterebbe una), 
come hai fatto tu è chiarissimo.



--
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Piergiuliano Bossi]

2013/9/18 Riccardo Lemmi 

>
>
> Mi sfugge il caso, forse un esempio chiarirebbe... L'unico posto in cui
> vedo male il codice messo sopra è quello in cui si usano gli elementi
> dell'array non in sequenza ma pescando in "qua e la'"
>
>
Ho visto la luce.

Questo e' il codice che ha causato il thread (semplificato, ovviamente);

def evaluate(list):
return sum(v for v in list if v % 2 == 0)

def _subtract(list1, list2):
result = list1[:]
for val in list2:
result.remove(val)
return result

def useless(list):
useful = list[:]
for val in list:
useful.remove(val)
if evaluate(useful) != evaluate(list):
useful.append(val)
return _subtract(list, useful)

if __name__ == "__main__":
print(useless([]))# => []
print(useless([1, 2, 3, 5, 8]))# => [1, 3, 5]

Codice abbastanza orrido, no?

L'idea e' calcolare gli elementi di una lista che non contribuiscono al
valore determinato da una certa funzione. Diciamo che evaluate in realta'
e' molto piu' complessa (non computazionalmente, ma matematicamente non e'
semplice), che e' insensibile all'ordine degli elementi nella lista (da cui
l'uso di remove non posizionale) e che ovviamente questo codice non e'
ottimizzato (eg: e' inutile chiamare evaluate(list) ogni volta nel ciclo).

L'ho riscritto senza copy.copy ma con [:] e ovviamente tutto bene, ma non
e' un gran guadagno. Poi ho provato a fare una comprehension che fa tutto
al volo e mi e' venuta al primo colpo:

def useless(list):
return [list[i] for i in range(len(list)) if evaluate(list[:i] +
list[i+1:]) == evaluate(list)]

Oserei dire che e' persino un pelo piu' comunicativa cosi', visto che non
devo calcolare una lista e poi sottrarla all'altra.

Mi sento come se avessi trovato il barattolo di nutella di Moretti, un
cucchiaione e nessuno attorno...  :)

Ciao
Giuliano

PS: queste sono le cose che fanno scattare l'aore...


-- 
Piergiuliano Bossi
Blog: http://thinkingbox.wordpress.com/
Twitter: http://twitter.com/thinkingbox (English)
Twitter: http://twitter.com/scatolapensante (Italiano)
Google+: https://plus.google.com/u/0/108187981162465525118
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Marco Beri]

2013/9/18 enrico franchi 

> Prendine atto. E' un dato di fatto. Python ha liste mutabili. Ogni volta
> che ho usato un linguaggio con liste mutabili (Python, Lisp) ho desiderato
> avere liste immutabili. Ogni volta che ho usato un linguaggio con liste
> immutabili, avrei voluto avere liste mutabili.
>

:-)


>  Aggiungo, io normalmente *non* uso [:].
>
> def __init__(self, people):
> self.people = list(people)
>
> Il motivo? Voglio avere controllo sulla struttura dati dentro la mia
> classe. E' mia responsabilita' e la voglio gestire io.
> Se voglio un set, faro' set(people), se voglio una lista faro' cosi'.
>
> In teoria il mio chiamante mi puo' legittimamente passare quello che gli
> pare, a patto che io possa costruirci una lista.
> Non voglio pero' essere limitato dalla semantica che lui ha scelto per la
> struttura dati che stava usando. Sia perche' potrebbe non implementare
> l'interfaccia che mi serve (e in questo caso sarebbe, diciamo, un errore
> suo), sia perche' e' proprio una sequenza diversa da una lista.
>

C'hai ragione c'hai...

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[enrico franchi]

2013/9/18 Piergiuliano Bossi 

In Python le liste sono mutabili e c'e' ben poco che si possa fare senza
> mutarle manipolandole,
>

Prendine atto. E' un dato di fatto. Python ha liste mutabili. Ogni volta
che ho usato un linguaggio con liste mutabili (Python, Lisp) ho desiderato
avere liste immutabili. Ogni volta che ho usato un linguaggio con liste
immutabili, avrei voluto avere liste mutabili.

Semplicemente ci sono classi di problemi che si risolvono meglio con una
struttura dati mutabile e altri con una immutabile. In alcuni casi scrivere
funzionale e' semplicemente una cosa vincente, in altri casi ha un costo
sulle performance tendenzialmente fastidioso.


> per cui in un metodo che riceve una lista in ingresso mi sono trovato
> spesso a copiarle in una variabile locale prima di lavorarci sopra:
>

Questo e' semplicemente un problema tipico della programmazione ad oggetti
classica (ovvero escludendo linguaggi ad oggetti che lavorano
principalmente con oggetti immutabili). E lo risolvi esattamente negli
stessi modi. Tipicamente non vuoi azione a distanza.

Ovvero, in quei casi in cui sei ragionevolmente sicuro che la lista che ti
viene passata non mantenga reference al di fuori del tuo mondo, puoi anche
non copiarla. In quei casi in cui invece hai timore che succeda, la devi
copiare. Ma lo stesso faresti con qualunque oggetto mutabile che non abbia
un'identita' personale.

Poi figurati, ti capisco. Vorrei *tanto* avere liste immutabili. Ah, uno di
questi giorni...

Usare un array.array non cambia le cose di fatto, introducendo tutta
> un'altra categoria di limitazioni.
>

Array serve per cose ben precise. Salva la vita, a volte, ma non e questo
il caso.

Le tuple sono immutabili, ma non funzionano nel senso che ho spiegato sopra
> (si', lo so, per la append potrei creare una nuova tupla e passarle in
> ingresso una lista concatenata della vecchia tupla e del nuovo elemento, ma
> non mi sembra il modo in cui il BDFL le ha intese).
>

Ottima intuizione. Non lo e'.


> Per cui la mia domanda e', quando volete manipolare strutture tipo array
> senza mutarle o mutandole in copia:
> 1) le copiate all'inizio come dicevo sopra
>

Esatto.


> 2) non usate liste, ma tuple, ma poi come compensate la mancanza di append
> e remove (sembra una contraddizione in termini ma non lo e', basterebbe che
> append e remove ritornino nuove strutture dati, copie dell'originale)
>

No no no no! :)



 Aggiungo, io normalmente *non* uso [:].

def __init__(self, people):
self.people = list(people)

Il motivo? Voglio avere controllo sulla struttura dati dentro la mia
classe. E' mia responsabilita' e la voglio gestire io.
Se voglio un set, faro' set(people), se voglio una lista faro' cosi'.

In teoria il mio chiamante mi puo' legittimamente passare quello che gli
pare, a patto che io possa costruirci una lista.
Non voglio pero' essere limitato dalla semantica che lui ha scelto per la
struttura dati che stava usando. Sia perche' potrebbe non implementare
l'interfaccia che mi serve (e in questo caso sarebbe, diciamo, un errore
suo), sia perche' e' proprio una sequenza diversa da una lista.


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

Re: [Python] Il dilemma degli array mutabili

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/09/2013 18:54, enrico franchi wrote:
> 2013/9/18 Piergiuliano Bossi  >
> 
> In Python le liste sono mutabili e c'e' ben poco che si possa fare
>  senza mutarle manipolandole,
> 
> 
> Prendine atto. E' un dato di fatto. Python ha liste mutabili. Ogni 
> volta che ho usato un linguaggio con liste mutabili (Python, Lisp) 
> ho desiderato avere liste immutabili. Ogni volta che ho usato un 
> linguaggio con liste immutabili, avrei voluto avere liste 
> mutabili.
> 

Ocaml, che ￨ famoso per essere pragmatico, mi sembra abbia entrambi.

> [...]


Ciao  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlI54esACgkQscQJ24LbaUTJMgCgjgA4zX2mcgCzeDsPZ3Ploabg
6qMAoJv54cIYJ2nnGkGSxSSkQltrFnYt
=fvxs
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[enrico franchi]

On Wed, Sep 18, 2013 at 4:34 PM, Lorenzo Sutton wrote:

>
> Ops.. volevo aggiungere questo :-)
> http://en.wikibooks.org/wiki/**Python_Programming/Tuples


Aggiungiamo una cosa... Non solo le tuple *non* sono liste immutabili.
Le tuple *non* sono una cosa per fare strutture dati.

Invito a riflettere su questi:

http://wescpy.blogspot.it/2012/05/tuples-arent-what-you-think-theyre-for.html

http://jtauber.com/blog/2006/04/15/python_tuples_are_not_just_constant_lists/
http://news.e-scribe.com/397

Nota a margine: quando si dice che le liste sono omogenee, non vuole dire
che *debbano* esserlo.
Ma credo che raramente vogliamo trovarci con liste i cui elementi non
abbiano un qualche supertipo dinamico (anche perche' poi sarebbe un casino
usarli). Viceversa, e' comunissimo avere tuple disomogenee.

 In altre parole, le liste e le tuple hanno due funzioni ben diverse,
nonostante l'apparente somiglianza. Le tuple sono piu' vicine ad una struct
che ad un array. Le liste... beh, le liste sono array (dinamici)! :)

BTW, le namedtuples sono splendide e rendono ancora piu' evidente
l'analogia fra le tuple normali e le struct. Sono, in un certo senso,
l'anello di collegamento.



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

Re: [Python] Il dilemma degli array mutabili

[Lorenzo Sutton]

On 18/09/2013 17:14, Marco Beri wrote:

2013/9/18 Lorenzo Sutton mailto:lorenzofsut...@gmail.com>>

PS:


Sicuro, sicuro? :-)


Ops.. volevo aggiungere questo :-)
http://en.wikibooks.org/wiki/Python_Programming/Tuples

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

Re: [Python] Il dilemma degli array mutabili

[Piergiuliano Bossi]

2013/9/18 Riccardo Lemmi 

>
>
> Crei la nuova lista leggendo da quella vecchia:
>
> newl = []
> for i in oldl:
>newl.append(applica_shifezze_varie_su(i))
>
> (stessa cosa con le comprehension)
>
>
Si', anche questa e' una possibilita'.


>
>
> Mi sfugge il caso, forse un esempio chiarirebbe... L'unico posto in cui
> vedo male il codice messo sopra è quello in cui si usano gli elementi
> dell'array non in sequenza ma pescando in "qua e la'"
>
>
Questione di come concepisci un algoritmo: mi immagino che qualunque
algoritmo che fa remove puo' essere ridisegnato per operare nel modo che
suggerisci tu (ci vorrebbe un bel teoremino... :) ), ma magari non viene
naturalmente in quel modo.

Poi recupero un paio di esempi per come li ho scritti facendo una copia e
poi lavorando di append/remove e provo a riscriverli nel modo suggerito e
magari rispondo a questo messaggio per farvi vedere cosa e' venuto fuori.

Grazie e ciao
Giuliano


-- 
Piergiuliano Bossi
Blog: http://thinkingbox.wordpress.com/
Twitter: http://twitter.com/thinkingbox (English)
Twitter: http://twitter.com/scatolapensante (Italiano)
Google+: https://plus.google.com/u/0/108187981162465525118
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Marco Beri]

2013/9/18 Lorenzo Sutton 

> PS:


Sicuro, sicuro? :-)

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Lorenzo Sutton]

On 18/09/2013 17:00, Piergiuliano Bossi wrote:

2013/9/18 Marco Beri mailto:marcob...@gmail.com>>

2013/9/18 Piergiuliano Bossi mailto:pgbo...@gmail.com>>

2) non usate liste, ma tuple, ma poi come compensate la mancanza
di append e remove (sembra una contraddizione in termini ma non
lo e', basterebbe che append e remove ritornino nuove strutture
dati, copie dell'originale)


Premetto che questa cosa dei parametri immutabili non è risolvibile
come vorresti tu.


Ad ogni modo un append immutabile è come se ci fosse:
 >>> a = (1, 2, 3, 4)
 >>> a += (5, 6)  # Appendi due elementi ad una copia della vecchia
sequence
 >>> a
(1, 2, 3, 4, 5, 6)


La remove è in effetti un po' più rognosa e bruttina:

 >>> a = (1, 2, 3, 4, 5)
 >>> a = a[:3] + a[3+1:]  # Rimuove il terzo elemento da una copia
della vecchia sequence
 >>> a
(1, 2, 3, 5)



Beh, non male, potrei scrivermi dei metodi che fanno queste cose in un
modo un po' piu' esplicito, ma l'idea c'e'. Eg: remove((1, 2, 3, 4, 5),
3) == (1, 2, 3, 5)


Forse anche questi potreberro esserti utili...? :-)

>>> t = (1,2,3,4,5)
>>> t[:-1] # Simil pop
(1, 2, 3, 4)
>>> t[::-1]# Simil reverse
(5, 4, 3, 2, 1)

>>> # Simil remove (in effetti non bellissimo...)
>>> t[:t.index(2)] + t[t.index(2)+1:]
(1, 3, 4, 5)
>>> # Stesso errore di list se provi a rimuovere qualcosa che non c'è
>>> t[:t.index(100)] + t[t.index(100) +1:]

Traceback (most recent call last):
  File "", line 1, in 
t[:t.index(100)] + t[t.index(100) +1:]
ValueError: tuple.index(x): x not in tuple

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

Re: [Python] Il dilemma degli array mutabili

[Piergiuliano Bossi]

2013/9/18 Marco Beri 

> 2013/9/18 Piergiuliano Bossi 
>
>> 2) non usate liste, ma tuple, ma poi come compensate la mancanza di
>> append e remove (sembra una contraddizione in termini ma non lo e',
>> basterebbe che append e remove ritornino nuove strutture dati, copie
>> dell'originale)
>>
>
> Premetto che questa cosa dei parametri immutabili non è risolvibile come
> vorresti tu.
>
>
> Ad ogni modo un append immutabile è come se ci fosse:
> >>> a = (1, 2, 3, 4)
> >>> a += (5, 6)  # Appendi due elementi ad una copia della vecchia sequence
> >>> a
> (1, 2, 3, 4, 5, 6)
>
>
> La remove è in effetti un po' più rognosa e bruttina:
>
> >>> a = (1, 2, 3, 4, 5)
> >>> a = a[:3] + a[3+1:]  # Rimuove il terzo elemento da una copia della
> vecchia sequence
> >>> a
> (1, 2, 3, 5)
>
>
>
Beh, non male, potrei scrivermi dei metodi che fanno queste cose in un modo
un po' piu' esplicito, ma l'idea c'e'. Eg: remove((1, 2, 3, 4, 5), 3) ==
(1, 2, 3, 5)


> In questo modo anche se uno ti passa una lista, in uscita te la troverai
> immutata.
> Comunque, come dice Manlio, la cosa migliore è di fartene una copia subito:
>
> Poi, per preferenza personale, io preferisco copiare una sequence così:
>
> a = a[:]
>
>
Capito, grassie.

Giuliano


-- 
Piergiuliano Bossi
Blog: http://thinkingbox.wordpress.com/
Twitter: http://twitter.com/thinkingbox (English)
Twitter: http://twitter.com/scatolapensante (Italiano)
Google+: https://plus.google.com/u/0/108187981162465525118
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Piergiuliano Bossi]

2013/9/18 Manlio Perillo 

>
> Che io ricordi, non ho mai usato copy/deepcopy in vita mia (forse una
> volta).
> Se devo copiare un dizionario faccio d.copy(), con una lista v[:].
>
>
Ah, ottimo suggerimento, non avevo pensato a v[:] :)


> > 2) non usate liste, ma tuple, ma poi come compensate la mancanza di
> > append e remove (sembra una contraddizione in termini ma non lo e',
> > basterebbe che append e remove ritornino nuove strutture dati,
> > copie dell'originale)
>
> Le tuple non sono liste immutabili.
>

Non ho sostenuto il contrario, vero?


> E' lo stesso problema con le bytestring e le string in Python 3.x, in
> cui le bytestring non rappresentano del testo e quindi non
> implementano gli stessi metodi che hanno in Python 2.x (anche se mi
> sembra ci abbiano in parte ripensato).
>
>
Certo, non hai a disposizione gli stessi metodi di manipolazione, quello e'
chiaro ed e' un po' il punto che facevo anch'io.


> > 3) vi toccate (cit)
> >
>
> Se devi modificare un parametro, e le modifiche devono essere
> "private", si copia, altrimenti sei un criminale/sprovveduto.
>
>
Si', il contesto era per l'appunto modifiche "private" al metodo.

Grazie e ciao
Giuliano

-- 
Piergiuliano Bossi
Blog: http://thinkingbox.wordpress.com/
Twitter: http://twitter.com/thinkingbox (English)
Twitter: http://twitter.com/scatolapensante (Italiano)
Google+: https://plus.google.com/u/0/108187981162465525118
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Marco Beri]

2013/9/18 Piergiuliano Bossi 

> 2) non usate liste, ma tuple, ma poi come compensate la mancanza di append
> e remove (sembra una contraddizione in termini ma non lo e', basterebbe che
> append e remove ritornino nuove strutture dati, copie dell'originale)
>

Premetto che questa cosa dei parametri immutabili non è risolvibile come
vorresti tu.


Ad ogni modo un append immutabile è come se ci fosse:
>>> a = (1, 2, 3, 4)
>>> a += (5, 6)  # Appendi due elementi ad una copia della vecchia sequence
>>> a
(1, 2, 3, 4, 5, 6)


La remove è in effetti un po' più rognosa e bruttina:

>>> a = (1, 2, 3, 4, 5)
>>> a = a[:3] + a[3+1:]  # Rimuove il terzo elemento da una copia della
vecchia sequence
>>> a
(1, 2, 3, 5)


In questo modo anche se uno ti passa una lista, in uscita te la troverai
immutata.
Comunque, come dice Manlio, la cosa migliore è di fartene una copia subito:

Poi, per preferenza personale, io preferisco copiare una sequence così:

a = a[:]

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Manlio Perillo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 18/09/2013 15:05, Piergiuliano Bossi wrote:
> Un'altra cosa che mi spiazza e' la seguente: sono abituato a 
> manipolare e trasformare array immutabili, in cui ogni 
> trasformazione ti ritorna una copia dell'array di partenza, per
> cui ci puoi fare le piu' immani schifezze senza effetti
> collaterali. [...] Per cui la mia domanda e', quando volete
> manipolare strutture tipo array senza mutarle o mutandole in copia:
> 1) le copiate all'inizio come dicevo sopra

Che io ricordi, non ho mai usato copy/deepcopy in vita mia (forse una
volta).
Se devo copiare un dizionario faccio d.copy(), con una lista v[:].

> 2) non usate liste, ma tuple, ma poi come compensate la mancanza di
> append e remove (sembra una contraddizione in termini ma non lo e',
> basterebbe che append e remove ritornino nuove strutture dati, 
> copie dell'originale)

Le tuple non sono liste immutabili.
E' lo stesso problema con le bytestring e le string in Python 3.x, in
cui le bytestring non rappresentano del testo e quindi non
implementano gli stessi metodi che hanno in Python 2.x (anche se mi
sembra ci abbiano in parte ripensato).

> 3) vi toccate (cit)
> 

Se devi modificare un parametro, e le modifiche devono essere
"private", si copia, altrimenti sei un criminale/sprovveduto.


> [...]


Ciao  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlI5scUACgkQscQJ24LbaUTYWwCfb8WGO7cvXAJuX9EE/fWH/z6L
gy0AnAudOj9O3usU9rP90q78PlAqI7+F
=MLJs
-END PGP SIGNATURE-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Il dilemma degli array mutabili

[Riccardo Lemmi]

Piergiuliano Bossi wrote:

> Un'altra cosa che mi spiazza e' la seguente: sono abituato a
> manipolare e trasformare array immutabili, in cui ogni trasformazione
> ti ritorna una copia dell'array di partenza, per cui ci puoi fare le
> piu' immani schifezze senza effetti collaterali.
> ...

Crei la nuova lista leggendo da quella vecchia:

newl = []
for i in oldl:
   newl.append(applica_shifezze_varie_su(i))

(stessa cosa con le comprehension)

> In Python le liste sono mutabili e c'e' ben poco che si possa fare
> senza mutarle manipolandole, per cui in un metodo che riceve una lista
> in ingresso mi sono trovato spesso a copiarle in una variabile locale
> prima di lavorarci sopra:
> import copy
> def yada(foo):
> bar = copy.copy(foo)
> # ecc.
> 
> Usare un array.array non cambia le cose di fatto, introducendo tutta
> un'altra categoria di limitazioni. Le tuple sono immutabili, ma non
> funzionano nel senso che ho spiegato sopra (si', lo so, per la append
> potrei creare una nuova tupla e passarle in ingresso una lista
> concatenata della vecchia tupla e del nuovo elemento, ma non mi sembra
> il modo in cui il BDFL le ha intese).
> 
> Per cui la mia domanda e', quando volete manipolare strutture tipo
> array senza mutarle o mutandole in copia:
> 1) le copiate all'inizio come dicevo sopra
> 2) non usate liste, ma tuple, ma poi come compensate la mancanza di
> append e remove (sembra una contraddizione in termini ma non lo e',
> basterebbe che append e remove ritornino nuove strutture dati, copie
> dell'originale) 3) vi toccate (cit)
> 
> Ho come la sensazione che Marco dira': usa una comprehension, che non
> e' una cattiva idea, ci mancherebbe, ma le comprehension mal si
> prestano quando l'algoritmo che stai implementando e' modellato su
> append() e remove() o sbaglio?
> 
> Grazie e ciao
> Giuliano
> 

Mi sfugge il caso, forse un esempio chiarirebbe... L'unico posto in cui 
vedo male il codice messo sopra è quello in cui si usano gli elementi 
dell'array non in sequenza ma pescando in "qua e la'"

-- 
   Riccardo Lemmi

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

[Python] Il dilemma degli array mutabili

[Piergiuliano Bossi]

Un'altra cosa che mi spiazza e' la seguente: sono abituato a manipolare e
trasformare array immutabili, in cui ogni trasformazione ti ritorna una
copia dell'array di partenza, per cui ci puoi fare le piu' immani schifezze
senza effetti collaterali.

In Python le liste sono mutabili e c'e' ben poco che si possa fare senza
mutarle manipolandole, per cui in un metodo che riceve una lista in
ingresso mi sono trovato spesso a copiarle in una variabile locale prima di
lavorarci sopra:
import copy
def yada(foo):
bar = copy.copy(foo)
# ecc.

Usare un array.array non cambia le cose di fatto, introducendo tutta
un'altra categoria di limitazioni. Le tuple sono immutabili, ma non
funzionano nel senso che ho spiegato sopra (si', lo so, per la append
potrei creare una nuova tupla e passarle in ingresso una lista concatenata
della vecchia tupla e del nuovo elemento, ma non mi sembra il modo in cui
il BDFL le ha intese).

Per cui la mia domanda e', quando volete manipolare strutture tipo array
senza mutarle o mutandole in copia:
1) le copiate all'inizio come dicevo sopra
2) non usate liste, ma tuple, ma poi come compensate la mancanza di append
e remove (sembra una contraddizione in termini ma non lo e', basterebbe che
append e remove ritornino nuove strutture dati, copie dell'originale)
3) vi toccate (cit)

Ho come la sensazione che Marco dira': usa una comprehension, che non e'
una cattiva idea, ci mancherebbe, ma le comprehension mal si prestano
quando l'algoritmo che stai implementando e' modellato su append() e
remove() o sbaglio?

Grazie e ciao
Giuliano


-- 
Piergiuliano Bossi
Blog: http://thinkingbox.wordpress.com/
Twitter: http://twitter.com/thinkingbox (English)
Twitter: http://twitter.com/scatolapensante (Italiano)
Google+: https://plus.google.com/u/0/108187981162465525118
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python