Topic: Libri veri, di carta..(consigliati)  (Letto 22812 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline Giornale di Sistema

  • python sapiens sapiens
  • ******
  • Post: 3.124
  • Punti reputazione: 4
    • Mostra profilo
    • Distillato di Python
Re: Libri veri, di carta..(consigliati)
« Risposta #165 il: Ottobre 21, 2015, 11:22 »
non linciatemi, ma per iniziare pure questa sembra buona ( anche se è un pdf)  http://linuxdidattica.org/polito/manuale-python-V2.pdf
qui si parte proprio dalla base della base :P

Considerato che il target è "ragazzi di età compresa tra i 10 e i 14 anni circa" e che si tratta di "una prima stesura", sembra carino.
Guardandolo a volo d'uccello qualcosa si nota:
  • si usa raw_input() per le stringhe, e input() per i numeri perché
    Citazione
    input è il comando che diamo al computer e che serve a inserire un numero nella scatola (variabile)
    oppure perché:
    Citazione
    La differenza consiste nel fatto che raw_input raccoglie i caratteri immessi dall'utilizzatore e li presenta sotto forma di stringa,
    mentre input li raccoglie e cerca di interpretarli come numero.
    int() non pervenuto.
  • Le variabili sono
    Citazione
    scatole che contengono qualcosa
    e di cui se ne può fare la "copiatura".
  • Dopo aver preannunciato che lo step 10 servirà anche a illustrare
    Citazione
    quando è opportuno utilizzare l'istruzione while o piuttosto l'istruzione for
    del for si perdono le tracce. Per fortuna ricompare nello step 11, ma giusto come sostituto più semplice di un while per iterare su una lista.
  • Allo step 12 si scrive codice per pygame senza spiegare che va installato a parte. Dato che tutto il codice precedente funzionava senza fare altro che scriverlo e avviarlo,
    ad un bambino di 10 anni può essere importante farlo presente, non è scontato che ottenga errori nell'esecuzione del codice e arrivi da solo a capire il problema.

potrebbe servire a qualcuno che si vuole avvicinare a python senza sborsare soldi per mattoni che poi non leggerà ;)

Nel link riportato nel messaggio precedente al tuo ci sono libri anche free ed in italiano.
« Ultima modifica: Ottobre 21, 2015, 15:29 da Giornale di Sistema »

Offline GlennHK

  • python sapiens sapiens
  • ******
  • Post: 1.655
  • Punti reputazione: 1
    • Mostra profilo
    • La Tana di GlennHK
Re: Libri veri, di carta..(consigliati)
« Risposta #166 il: Ottobre 21, 2015, 11:35 »
No, ma seriamente...

Un manuale che spiega python usando esempi con l'indentazione sbagliata e caratteri non monospaced? Poi per 10-14 anni...

No grazie.

Offline Birkhoff92

  • python unicellularis
  • *
  • Post: 6
  • Punti reputazione: 0
    • Mostra profilo
Re: Libri veri, di carta..(consigliati)
« Risposta #167 il: Ottobre 22, 2015, 08:16 »
ahahahah era per dire XD io comunque trovo utile learning in python ma costa un botto. Per ora me l'han prestato. Per l'università mi serve in quanto stiamo facendo socket per reti di calcolatori

Offline Giornale di Sistema

  • python sapiens sapiens
  • ******
  • Post: 3.124
  • Punti reputazione: 4
    • Mostra profilo
    • Distillato di Python
Re: Libri veri, di carta..(consigliati)
« Risposta #168 il: Ottobre 22, 2015, 09:36 »
comunque trovo utile learning in python ma costa un botto. Per ora me l'han prestato. Per l'università mi serve in quanto stiamo facendo socket per reti di calcolatori

Ma, questo Learning Python? Non mi pare ci sia roba sui socket... forse è più indicato Foundations of Python Network Programming oppure Python Network Programming Cookbook.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: Libri veri, di carta..(consigliati)
« Risposta #169 il: Ottobre 24, 2015, 10:13 »
comunque trovo utile learning in python ma costa un botto. Per ora me l'han prestato. Per l'università mi serve in quanto stiamo facendo socket per reti di calcolatori

Ma, questo Learning Python? Non mi pare ci sia roba sui socket... forse è più indicato Foundations of Python Network Programming oppure Python Network Programming Cookbook.

Si, sul cookbook IIRC qualcosa c'e'. Ma comunque non c'e' molto da sapere di "python related". Meglio un libro sulla programmazione di rete e poi leggere la doc online per Python. :)

Offline guano

  • python unicellularis
  • *
  • Post: 39
  • Punti reputazione: 0
    • Mostra profilo
Re: Libri veri, di carta..(consigliati)
« Risposta #170 il: Marzo 31, 2016, 16:57 »
Introduction to Computer Science Using Python: A Computational Problem-Solving Focus

Notare la recensione di Guido. Ah, sí, e pure il prezzo a dire il vero.

Qualcuno l'ha letto? Sembra molto molto interessante e stavo giustappunto ponderando la possibilità di vendere un rene (scherzi a parte, deve esserci un errore nel prezzo).

EDIT: già, decisamente più accessibile su amazon.com

EDIT: okay, sono riuscito a rimediarlo ed effettivamente è fatto apposta per un principiante come me. Analisi del problema, design, implementazione (il primo programma è il calcolo dell'equazione di Drake, 10 punti in più): decisamente interessante. Me lo leggerò dopo aver finito Learning Python.

Un pocket ad esempio...
Python pocket (M. Beri). C'è anche la versione digitale a 5€, la trovi in una discussione recente.
Python in Tasca.
Python di Lutz (pocket).
Avendoli letti tutti e tre, ma comprato solo uno, ti consiglio quello di Lutz (14 €). Il libro di Marco è pure ottimo.
Ciao,
Marco.

Boh, io ho dato un'occhiata al pocket reference di Lutz, ma mi è sembrato copiato pari pari dalla documentazione ufficiale. Non ne capisco il senso, francamente; cioè, capisco che a Lutz non dispiaccia avere 15€ in più in tasca, però... sembra fatto per persone che si sono scordate di pagare la bolletta telefonica e che pertanto non possono accedere a internet: un pubblico piuttosto circoscritto.
« Ultima modifica: Marzo 31, 2016, 17:54 da guano »

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: Libri veri, di carta..(consigliati)
« Risposta #171 il: Aprile 03, 2016, 17:54 »
Introduction to Computer Science Using Python: A Computational Problem-Solving Focus

> Notare la recensione di Guido. Ah, sí, e pure il prezzo a dire il vero.

In USA costa meno. Tipo la meta'.
http://www.amazon.com/Introduction-Computer-Science-Using-Python/dp/0470555157/ref=cm_cr_arp_d_product_top?ie=UTF8

e usato non si prende male.

> Qualcuno l'ha letto? Sembra molto molto interessante e stavo giustappunto ponderando la possibilità di vendere un rene (scherzi a parte, deve esserci un errore nel prezzo).

Sinceramente? No. E non intendo leggerlo. Non e' che sia un libro che mi possa essere vagamente utile. E' un peccato, ma fintanto che non si prendono la briga di mandarmeli a casa gratis, non posso stare a comprare ogni libro su Python. 10 anni fa si poteva anche fare, ora sono troppi.

Citazione
EDIT: okay, sono riuscito a rimediarlo ed effettivamente è fatto apposta per un principiante come me. Analisi del problema, design, implementazione (il primo programma è il calcolo dell'equazione di Drake, 10 punti in più): decisamente interessante. Me lo leggerò dopo aver finito Learning Python.

Questo libro mi incuriosisce. Da quello che leggo sulle recensioni ci sono aspetti che approvo e aspetti che non approvo. Per esempio, approvo moltissimo il concetto di fare problem solving. Non approvo per nulla l'idea di fare, nel 2016, programmazione strutturata.

Onestamente, credo che la programmazione strutturata sia stata una sovra-reazione ad una serie di problemi che erano piuttosto diffusi all'epoca. Adesso e' un insieme di norme piuttosto antistoriche. Diciamo che oggigiorno la considero piu' dannosa che interessante.

1. fin dai fondamenti immagina un linguaggio essenzialmente imperativo. Anzi... il fatto stesso che abbia il concetto di ordinamento negli statement dice che parla di programmazione imperativa. Siccome oggigiorno quasi tutti i linguaggi hanno discreti aspetti di programmazione funzionale, gia' comincio a sentire puzza.
2. di fatto non gestisce uno degli aspetti piu' importanti della programmazione moderna, che e' la struttura ad oggetti. certo... alcuni linguaggi (specie funzionali) hanno un modello piuttosto diverso da quello ad oggetti (che comunque non e' coperto). insomma... in un mondo in cui i singoli metodi sono *gia'* considerati puzzolenti se vanno oltre poche decine di righe, il focus e' chiaramente quello sbagliato.
3. immagina un modello di gestione dell'errore completamente fuori di melone. poteva andare bene per i teorici che scrivono programmi "puri". Purtroppo, noialtri abbiamo un dominio molto piu' complesso e ambiguo. Hai chiamate a servizi esterni (che possono fallire per seicento motivi diversi) e un sacco di roba che ha lo stesso problema. La gestione dell'errore e' una delle parti piu' complicate di un programma moderno. La discussione si e' spostata su altri lidi... l'idea di un paradigma che di fatto proibisce le eccezioni (se non con estensioni ad hoc che spesso sfociano nel ridicolo: l'idea di Jim Bonang e' particolarmente assurda, ma la dice lunga su chi ami la programmazione strutturata) e' completamente assurda. E nota... personalmente non sono un gran fan delle eccezioni castrate comunemente diffuse; preferisco o eccezioni vere alla Lisp (con tutti i problemi e le complicazioni che portano) oppure la gestione degli errori di Go... la quale viola tipicamente il principio di un singolo punto di uscita.
4. Un solo punto di entrata? Ok, ci siamo giocati le coroutine. Brillante.
5. Un solo punto di uscita? Via al balletto delle ridicole flag.
6. concorrenza... qualcuno ha detto concorrenza? ah, si... gli accademici hanno certamente inventato qualche modello arricchito anche per questo.

No grazie. Non faccio programmazione strutturata. Devo scrivere codice leggibile per essere umani, non posso permettermi di attenermi a leggi arcaiche e discutibili. No. Un punto di uscita e un punto di entrata non serve a una beneamata mazza. O meglio, serve solo a quelli che fanno dimostrazioni formali *a mano*. Che se gia' le fai in modo automatico, puoi ampiamente applicare trasformazioni al programma per scriverlo come ti pare e ridurlo nella forma che vuoi.

Quindi non mi dai break e continue? Ma sei completamente pazzo?
Ma guarda, quando ci vuole ci ficco anche un bel goto. Anche perche' tanto i linguaggi "moderni" che ti concedono goto, non ti concedono il goto di Dijkstra. Ti concedono, di fatto, un goto locale. Poi si... in C ho anche setjump e compagnia. Che ci sa che ci sono sa quanto sono complicati da gestire e sa anche che sebbene in determinati contesti siano proprio una manna, nel caso generale hanno una tale complicazione che non ne vale la pena. Insomma... sono strumenti complicati da usare per fare cose complicate. Che vuole dire che la gente non li usa a sproposito.

Supponiamo di volere scrivere una funzione che itera una sequenza e mi risponde se  contiene un determinato valore.

Scriviamola in Python.

[codice]
def has_item(seq, item):
  for el in seq:
    if item == el:
      return True
  return False
[/codice]


Non credo che ci sia un modo piu' coinciso e leggibile di scriverlo. E' *esattamente* come descriveremmo l'algoritmo a parole. Ha anche efficienza ottima: dobbiamo per forza fare una scansione lineare (per come e' fatto il problema), ma siamo in grado di uscire al primo momento in cui troviamo l'elemento.

Pensiamola ora in programmazione strutturata... abbiamo un po' di opzioni, una piu' demenziale dell'altra.

Opzione 1: lenta ma chiara

[codice]
def has_item(seq, item):
  flag = False
  for el in seq:
    if item == el:
      flag = True
  return flag
[/codice]

Allora, siamo un po' piu' lunghi e un po' meno chiari. Ma soprattutto sta volta dobbiamo farci tutto quanto il ciclo, anche se troviamo subito l'elemento.

Opzione 2: non pythonica, confusa, ma efficiente (almeno dal punto di vista dei confronti)

[codice]
def has_item(seq, item):
  notFound = True
  index = 0

  while notFound:
    el = seq[index]
    if el == item:
      notFound = False
    index += 1

  return not notFound
[/codice]

Ora due cose... so gia' che contiene un baco (se la sequenza e' vuota). E non sono piu' convinto che questo codice sia corretto. La prima versione non l'ho nemmeno testata, e al di la dell'imbarazzo se ho ciccato un codice cosi' semplice scrivendolo di getto nel forum... sono abbastanza convinto che sia corretta. Quest'ultima versione... boh. Sembra corretta. Ma devo leggerla tre volte solo per convincermi che quel not notFound sia corretto. Forse sarebbe stato piu' chiaro usare una flag "found". vabbe'... vediamo


[codice]
def has_item(seq, item):
  found = False
  index = 0

  while not found:
    el = seq[index]
    if el == item:
      found = True
    index += 1

  return found
[/codice]

si, meglio. Piu' chiaro. Ora gestiamo la sequenza nulla... sarebbe bello scrivere if not seq: return False; ma non possiamo. Il MinCulPop ha detto che non si puo'.

Nel frattempo mi sono reso conto di un errore non da poco... scusate. Che non era quello che avevo immaginato.
Ho toppato, non sono perfetto. Non e' una finta, non e' una cosa didattica. Mentre ero consapevole del fatto che la prima versione non gestiva correttamente la sequenza vuota, non mi ero accorto che c'e' un baco grosso come una casa in quella funzione.

E io *onestamente* non lo ho visto subito... me ne sono accorto andando a pensare come risolvere il fatto che la sequenza sia vuota. Il baco e' che ovviamente se l'elemento non c'e', quella funzione esce con un index error. Bene... non va bene.

Oh... scrivo codice da troppo tempo. Ci mangio. Scrivo anche roba abbastanza complicata in genere. Eppure... ho infilato un baco da cretino in una funzione di 10 linee per cercare un elemento in una sequenza. Funzione che ti scrivo ad occhi chiusi nella maggior parte dei casi. Ma mi introduci tutte le complicazioni della programmazione strutturata ed ecco che involontariamente sbaglio.

[codice]
def has_item(seq, item):
  found = False
  stop = False
  index = 0

  if not seq:
    stop = True

  while not found and not stop:
    el = seq[index]
    if el == item:
      found = True
    index += 1
    if index >= len(seq):
      stop = True

  return found
[/codice]

Pare funzionare. Al solito... non sono convinto. Non mi fido del mio codice. La probabilita' che abbia un off by one da qualche parte e' altissima. Potrei semplificarlo? Forse, pensandoci ancora.

Cioe' diciamola chiara... se volessi mandare in produzione,  mi metterei li, farei tutti i test. Non credo sia utile. Posto quel codice dicendo: *davvero* non so se funziona. Potrebbero esserci bachi.

Quindi facciamo una breve analisi... siamo passati da 4 righe di codice a tipo 15. Siamo passati da un codice che non puo' essere piu' semplice ad un mezzo macello. Non siamo piu' sicuri che il codice faccia la cosa giusta. Abbiamo gia' scoperto che ci ho infilato un baco involontario. Ogni qualvolta qualcuno se lo deve capire, ci mettera' molto piu' tempo che l'istantanea occhiata al mio primo esempio. E tutto questo su una funzione *banale* che davvero non si dovrebbe scazzare e non puo' andare nulla male.

Sembra davvero una buona idea? A me sembra un idea veramente del ca**o.

Scusate... c'e' il terzo sistema. Che e' di fatto costruire un'iterabile su seq che in qualche modo si fermi prima. Ovvero in pratica ci stiamo andando ad infilare nel mondo della parte funzionale di Python... che sebbene in questo caso non violi nessun principio della programmazione strutturata. E viene fuori una roba tipo orribile:

[codice]def has_item(seq, item):
  it = itertools.dropwhile(lambda el: el != item, seq)
  found = True
  try:
    next(it)
  except StopIteration:
    found = False
  return found[/codice]

Ancora una volta... dovrebbe essere corretto. Ma lo sai tu? Non davvero. E vallo a leggere. Cioe' l'unica cosa che concludi e' che se scrivo una cosa del genere sono pazzo nel cervello.

Quindi... questo non vuole dire che il libro sia cattivo. E' un libro *opinionato*. Prendi con spirito critico quello che ci leggi. Studialo. Sono sicuro che c'e' da imparare. Ma renditi molto chiaro quella che e' un'opinione dell'autore, e sentiti libero di formarti la tua (dopo esserti documentato sui pro e sui contro).


Citazione
Boh, io ho dato un'occhiata al pocket reference di Lutz, ma mi è sembrato copiato pari pari dalla documentazione ufficiale. Non ne capisco il senso, francamente; cioè, capisco che a Lutz non dispiaccia avere 15€ in più in tasca, però... sembra fatto per persone che si sono scordate di pagare la bolletta telefonica e che pertanto non possono accedere a internet: un pubblico piuttosto circoscritto.

1. non ho presente affatto quel libro.
2. non e' che a Lutz arrivino 15 euro in tasca. secondo me se gliene arrivano 3 e' tanto.
3. posto che non posso parlare dello specifico libro, o'reilly ha sempre fatto vari pocket reference; qua sul mio tavolo a lavoro ne ho uno su sed&awk, uno su bash e dovrei averne uno su "linux". i primi due li uso spesso: onestamente a seconda di cosa stai "cercando" potrebbe essere che un libro compatto con un indice funzioni meglio (e.g., cercare ${foo,,} non e' esattamente banale). quello su "linux" lo uso meno spesso poiche' alla fine i comandi che uso spesso me li ricordo o ci faccio man, quelli che uso di rado non so come cercarli su quel libro, per cui non e' esattamente utile.

Offline guano

  • python unicellularis
  • *
  • Post: 39
  • Punti reputazione: 0
    • Mostra profilo
Re: Libri veri, di carta..(consigliati)
« Risposta #172 il: Aprile 12, 2016, 12:20 »
Beh, dai tre esempi che hai postato sembrerebbe proprio che la programmazione strutturata sia inutilmente error-prone, a dir poco prolissa e, per finire, dannatamente complicata da leggere: insomma, il male assoluto.

Dunque, se ho capito bene, nel caso specifico il cuore del problema sta nel fatto che la funzione del primo script ha due punti di uscita (i due return) e questo viola i canoni della programmazione strutturata. In effetti, non ne capisco la ratio.  Per fare la stessa cosa, ossia per fermare il ciclo anzitempo qualora sia trovato l'elemento desiderato all'interno della sequenza, lo stesso programma coerente ai suddetti principi (mi riferisco al secondo esempio) introduce due variabili preposte al controllo del ciclo, ossia found e stop, i cui valori variano al variare dei valori di altre variabili, determinando prima  l'eventuale avvio del ciclo, e nel caso la sua fine. E tutto questo solo per avere un solo punto di uscita dalla funzione? Ho capito bene?

Beh, se ho capito bene, sembrerebbe proprio un'inutile complicazione - per usare un eufemismo. Suppongo, tuttavia, che la questione di avere un punto di entrata ed un punto di uscita abbia una qualche spiegazione razionale. Voglio dire, ci deve pur essere un motivo valido che giustifichi questo casino.

Ad ogni modo, faró come dici. Studieró con spirito critico il testo in questione. Ti ringrazio per l'avvertimento.

Offline riko

  • python deus
  • *
  • moderatore
  • Post: 7.453
  • Punti reputazione: 12
    • Mostra profilo
    • RiK0 Tech Temple
Re: Libri veri, di carta..(consigliati)
« Risposta #173 il: Aprile 12, 2016, 15:31 »
Beh, dai tre esempi che hai postato sembrerebbe proprio che la programmazione strutturata sia inutilmente error-prone, a dir poco prolissa e, per finire, dannatamente complicata da leggere: insomma, il male assoluto.

Ovviamente devi farti la tua opinione. E' facile presentare esempi negativi, omettere quelli positivi e giocarsela cosi'.

Citazione
Dunque, se ho capito bene, nel caso specifico il cuore del problema sta nel fatto che la funzione del primo script ha due punti di uscita (i due return) e questo viola i canoni della programmazione strutturata.

Esatto.

Citazione
In effetti, non ne capisco la ratio.  Per fare la stessa cosa, ossia per fermare il ciclo anzitempo qualora sia trovato l'elemento desiderato all'interno della sequenza, lo stesso programma coerente ai suddetti principi (mi riferisco al secondo esempio) introduce due variabili preposte al controllo del ciclo, ossia found e stop, i cui valori variano al variare dei valori di altre variabili, determinando prima  l'eventuale avvio del ciclo, e nel caso la sua fine. E tutto questo solo per avere un solo punto di uscita dalla funzione? Ho capito bene?
Esatto ancora.

Citazione
Beh, se ho capito bene, sembrerebbe proprio un'inutile complicazione - per usare un eufemismo. Suppongo, tuttavia, che la questione di avere un punto di entrata ed un punto di uscita abbia una qualche spiegazione razionale. Voglio dire, ci deve pur essere un motivo valido che giustifichi questo casino.

Ce ne sono parecchi. Intanto quando queste idee sono venute fuori, era oggettivamente un casino. Io non c'ero, ma la gente davvero programmava a botte di goto. E i goto che avevano allora, non erano come quelli che si trovano nei linguaggi "moderni". Tipicamente linguaggi che hanno goto (C, Go) supportano solo goto *locali* ad una funzione, non li usi per saltare dove accidenti ti pare e basta. E all'epoca le "procedure" erano una cosa "nuova" e "costosa". Insoma... storia diversa.

Poi c'e' tutto un discorso per chi vuole fare dimostrazioni formali di correttezza: avere un solo punto di entrata e di uscita semplifica moltissimo se fai a mano. Diciamo che se fai a mano puo' essere la differenza fra avere successo o non averlo. Adesso si fa tipicamente in modo automatico... io facevo quella roba circa 10 anni fa. E non mi ricordo di problemi immensi relativi: essenzialmente puoi applicare trasformazioni arbitrarie per ricondurre il programma nella forma che vuoi tu e l'analizzatore se la dovrebbe cavare. Probabilmente e' comunque molto piu' facile non avere il problema, ma siccome vuoi analizzare programmi reali e i programmi reali sono scritti da persone che devono scrivere codice, non farsi le pugnette sulla programmazione strutturata... beh, immaginati. :)

Citazione
Ad ogni modo, faró come dici. Studieró con spirito critico il testo in questione. Ti ringrazio per l'avvertimento.

Esatto.