[PYTHON] why not?

[cdimauro]

Il titolo del thread è già tutto un programma.
Sarebbe interessante conoscere ciò che di "negativo" gli altri programmatori pensano di questo linguaggio.

Le critiche, se costruttive, sono ben accette (quindi niente roba come "fa schifo", "non mi piace", "è brutto", ecc.), perché questo consente di apportare miglioramenti (la comunità che ruota attorno a Python è molto sensibile ai suggerimenti e tiene molto a cuore l'evoluzione del linguaggio e della libreria standard), di comprendere eventuali comportamenti scorretti nell'uso e/o eventuali "falle" strutturali del linguaggio, e in ogni caso di farsi un'idea di come gli altri programmatori preferisco lavorare e come vorrebbero che fossero gli strumenti che usano per sviluppare codice.

Questo thread vorrei, quindi, che divenisse un cantiere di lavoro in cui all'indicazione di una critica da parte di uno o più utenti seguisse un approfondimento (per chi se la sente, ovviamente) per cercare di sviscerare il problema, facendo saltare fuori magari qualche soluzione.

Spero raccolga il favore dei frequentatori del forum e diventi un punto di riferimento per questo linguaggio.

[cionci]

Io sinceramente il thread non lo chiamerei "why not ?"...anche perché "why not" presuppone risposte come "è illeggibile", che non è una critica costruttiva, visto che chiaramente rimarrà una caratteristica invariabile del linguaggio.

[cdimauro]

Il linguaggio, invece, è nato per essere leggibile: non a caso è stato definito "pseudocodice eseguibile".

Sulla leggibilità, quindi, abbiamo di che discutere.

Se è una questione di gusti e/o abitudini, invece, è chiaro che c'è ben poco da parlare: ognuno ha i suoi e si tratta di scelte prettamente individuali.

A me, ad esempio, non piacciono assolutamente i linguaggi con sintassi C-like.

[cionci]

Io mi ricordo del codice che ha postato te qualche tempo fa...
Capisco che le generator expression siano state inserite per cercare di rendere il linguaggio più vicino al modo di scrivere umano e fino ad un'espressione molto semplice ci riescono anche bene. Il problema è quando l'espressione è complicata.
Ti spiego secondo me qual è il problema: nel linguaggio parlato ci sono le pause e la tonalità della voce, in quello scritto c'è la punteggiatura.

Purtroppo in situazioni come queste non ci si capisce proprio niente:

g = (tgtexp for var1 in exp1 if exp2 for var2 in exp3 if exp4)

e ne ho presa una semplice
E' un po' la stessa cosa che avviene per le espressioni matematiche, solo che la precedenza fra gli operatori matematici ci è stata insegnata fino dalle elementari
Ad esempio un'altra cosa che non si capisce è cosa ci finisce in g...

[cdimauro]

Originariamente inviato da cionci

Io mi ricordo del codice che ha postato te qualche tempo fa...

Immaginavo. Però avevo anche fatto un mea culpa dicendo che il codice che avevo postato non era da prendere a campione e generalizzare annacquando il concetto di leggibilità del codice Python.

Capisco che le generator expression siano state inserite per cercare di rendere il linguaggio più vicino al modo di scrivere umano e fino ad un'espressione molto semplice ci riescono anche bene. Il problema è quando l'espressione è complicata.
Ti spiego secondo me qual è il problema: nel linguaggio parlato ci sono le pause e la tonalità della voce, in quello scritto c'è la punteggiatura.

Purtroppo in situazioni come queste non ci si capisce proprio niente:

g = (tgtexp for var1 in exp1 if exp2 for var2 in exp3 if exp4)

e ne ho presa una semplice

Infatti, ma anche i nomi delle variabili non aiutano molto...

Alla fine è pur sempre compito del programmatore utilizzare le strutture che un linguaggio mette a disposizione scrivendo un codice più leggibile.
Se quella generator expression la trovi troppo complicata, è compito tuo "spezzarla" in modo da renderla più leggibile e/o usare dei nomi per gli identificatori che la rendano di più semplice comprensione.

Ad esempio, se prendiamo quella che ho utilizzato in questo http://www.hwupgrade.it/forum/showpo...70&postcount=2 messaggio:

Lista = ['gasfsgafsagfsga', '', '', '', '  gahsfsga', 'ahsg']
with open('Pippo.txt', 'w') as f:
  f.writelines(Stringa + '\n' for Stringa in Lista)

Direi che è abbastanza semplice comprendere il funzionamento della generator expression.

E' un po' la stessa cosa che avviene per le espressioni matematiche, solo che la precedenza fra gli operatori matematici ci è stata insegnata fino dalle elementari
Ad esempio un'altra cosa che non si capisce è cosa ci finisce in g...

In g ci finisce un... generatore, appunto.

Il concetto è che hai un insieme di valori da elaborare, ma li tiri fuori man mano che ti servono, quindi ottimizzando le risorse (non si spreca memoria generandoli tutti in una volta). In altri linguaggi si chiamano iteratori.

Invece se avessi scritto questo:

g = [tgtexp for var1 in exp1 if exp2 for var2 in exp3 if exp4]

g sarebbe diventata una lista contenente TUTTI i valori che soddisfano le condizioni che hai posto.

La cosa interessante in entrambi i casi è che chi ha un'infarinatura di matematica si "ritrova a casa", visto che la sintassi richiama la definizione di un insieme i cui elementi soddisfano certe condizioni.

Comunque sia le list comprehension che le generator expression sono argomenti più avanzati, che si apprendono dopo aver acquisito i concetti più elementari del linguaggio.

Procedendo gradualmente noteresti che Python come linguaggio rimane piuttosto semplice e leggibile.

Se vuoi possiamo anche scrivere degli esempi di algoritmi e vedere come vengono resi con linguaggi diversi: si capirebbe al volo perché Python è stato definito "pseudocodice eseguibile".

[fek]

Originariamente inviato da cdimauro

Se è una questione di gusti e/o abitudini, invece, è chiaro che c'è ben poco da parlare: ognuno ha i suoi e si tratta di scelte prettamente individuali.

Per me e' una questione puramente di gusti, perche' non ho nulla di personale contro Python
Al lavoro c'e' tutto un sistema di decine e decine di migliaia di righe di codice in Python per fare il build degli asset e cerco di evitarlo come la peste. Ci avro' scritto dentro un centinaio di righe di codice a dire tanto.

[cdimauro]

D'accordo, ma mi piacerebbe capire se ci sono delle particolari caratteristiche del linguaggio sono ritenute errate per motivi che prescindono dai gusti.

Ad esempio so che a te non piace l'indentazione forzata a cui sei obbligato con Python, ma per quel poco che ti conosco sono convinto che non si tratti di una semplice questione di gusti, ma magari c'è qualche solida motivazione alla base del tuo rigetto.
Poi se è veramente una questione "epidermica", vorrà dire che avrò preso un'altra delle mie cantonate.

Per fare un altro esempio, Bruce Eckel vorrebbe veder sparire il parametro self "obbligatorio" nella definizione dei metodi (e, se non ricordo male, anche per l'accesso agli attribuiti e/o agli altri metodi) di una classe.
Qui l'argomento porterebbe a non poche discussioni.

A me, ad esempio, piacerebbe una soluzione "ibrida / intermedia": self non dovrebbe essere presente nella definizione / signature del metodo, ma nel corpo se si volesse accedere a un attributo e/o altro metodo si dovrebbe forzamente utilizzare il self, che a questo punto diventerebbe una sorta di variabile "nascosta" (ma disponibile) all'interno della funzione (perché i metodi, in Python, sono pur sempre delle funzioni, anche se "particolari").

Il motivo per cui finora si è rimasti saldamente all'implementazione attuale (self SEMPRE specificato) è che la filosofia di Python è "explicit is better than implicit", quindi alla volontà di far trasparire sempre tutto ciò con cui si lavora.

La condivido in buona parte, ma mantengo sempre le mie idee, che ritengo comunque valide.

[fek]

Originariamente inviato da cdimauro

Ad esempio so che a te non piace l'indentazione forzata a cui sei obbligato con Python, ma per quel poco che ti conosco sono convinto che non si tratti di una semplice questione di gusti, ma magari c'è qualche solida motivazione alla base del tuo rigetto.

L'indentazione forzata gia' da sola mi basta per farmelo evitare...

Per fare un altro esempio, Bruce Eckel vorrebbe veder sparire il parametro self "obbligatorio" nella definizione dei metodi (e, se non ricordo male, anche per l'accesso agli attribuiti e/o agli altri metodi) di una classe.
Qui l'argomento porterebbe a non poche discussioni.

... e il self sempre specificato ci mette una pietra tombale sopra. Python sembra fatto apposta perche' a me non piaccia.

Poi, se lo devo usare lo uso e buona notte.

[cionci]

Originariamente inviato da fek

Python sembra fatto apposta perche' a me non piaccia.

Poi, se lo devo usare lo uso e buona notte.

Idem
Cioè...per me non ha niente di attrattivo. Ad esempio è da una vita che critico il C++ perché non impone una struttura ad oggetti al programma e permette di mischiare programmazione procedurale ed a oggetti...Python fa lo stesso.

[cdimauro]

Originariamente inviato da fek

L'indentazione forzata gia' da sola mi basta per farmelo evitare...



... e il self sempre specificato ci mette una pietra tombale sopra. Python sembra fatto apposta perche' a me non piaccia.

Poi, se lo devo usare lo uso e buona notte.

OK, quindi è un problema di empatia: "a pelle" non ti piace.

Immagino, allora, che nemmeno la soluzione ibrida che mi piacerebbe non ti ispiri.

[cdimauro]

Originariamente inviato da cionci

Idem
Cioè...per me non ha niente di attrattivo. Ad esempio è da una vita che critico il C++ perché non impone una struttura ad oggetti al programma e permette di mischiare programmazione procedurale ed a oggetti...Python fa lo stesso.

Beh, in Python sono tutti oggetti.