linguaggio per far capire la programmazione

[MItaly]

Non capisco come faccia a piacere la sintassi di python

Elabora... io non capisco come faccia a non piacere...

[chumkiu]

Elabora... io non capisco come faccia a non piacere...

L'obbligo dell'indentazione per esempio o per fare un ciclo for devi creare un array (range(1,100)) e se ti serve un for sui numeri pari devi usare una comprensione di lista. "True" e "False" sono case sensitive.
Per carità... è simpatico. Potente per certi versi... ma non bello (IMO)

[Scara95]

So che ormai è stato deciso

io all'uni ho iniziato con Standard ML, lo consiglierei

perche' essendo un linguaggio funzionale eviti i casini degli effetti collaterali al neofita, per non parlare della sintassi molto semplice

Per evitare i casini sono anche d'accordo, ma per la sintassi per carità
Meglio un subset di Haskell nel caso...

In ogni caso sono d'accordo che Python sia una buona scelta!

[MItaly]

L'obbligo dell'indentazione per esempio

Questa invece per me è la trovata migliore. L'indentazione è un bene, il codice non indentato è illeggibile. Costringere ad indentare è cosa buona e giusta, e soprattutto l'indentazione è sempre giusta (=corrispondente ai blocchi compresi dall'interprete) per definizione (a differenza di linguaggi C-like dove un blocco indentato in maniera errata può farti sfuggire un bug).

o per fare un ciclo for devi creare un array (range(1,100))

Perché il "for" di Python è il "for each" di altri linguaggi; ma il linguaggio e i container sono fatti in maniera tale per cui nella gran parte dei casi iteri sul container, non sugli indici. Ovvero, se voglio esaminare gli elementi di una lista non faccio

for i in range(0, len(lista)):
    print lista[i]

ma direttamente

for elem in lista
    print elem

o, se mi serve anche l'indice,

for i, elem in enumerate(lista):
    print i, elem

In ogni caso, è vero che creare una lista completa per ogni range in Python può essere inefficiente, motivo per cui in Python 3 range è stato rimpiazzato con l'ex-xrange (che restituisce un generator con lazy evaluation).

e se ti serve un for sui numeri pari devi usare una comprensione di lista.

Perché mai?

for i in range(0, 100, 2):
    print i

(e le list comprehension, e soprattutto i sequence object, sono un'idea fottutamente geniale)

"True" e "False" sono case sensitive.

Perché non dovrebbero esserlo? Tutto in Python è case sensitive. Se convenga che un linguaggio sia case sensitive o case insensitive è questione su cui non intendo addentrarmi, la cosa fondamentale è che sia coerente (e non che faccia cose a caso tipo PHP, in cui le variabili sono case sensitive, le funzioni no, le costanti solo quando c'è la luna piena).

Per carità... è simpatico. Potente per certi versi... ma non bello (IMO)

Se non è bella la sintassi Python non so cosa si può dire di PHP, Perl, C++, bash, ...

[chumkiu]

Questa invece per me è la trovata migliore. L'indentazione è un bene, il codice non indentato è illeggibile. Costringere ad indentare è cosa buona e giusta, e soprattutto l'indentazione è sempre giusta (=corrispondente ai blocchi compresi dall'interprete) per definizione (a differenza di linguaggi C-like dove un blocco indentato in maniera errata può farti sfuggire un bug).

Secondo me i casi sono troppi e troppo vari per imporre una regola così forte. Allunghi le linee di codice anche quando non è necessario. Per me deve rimanere una buona pratica e non una imposizione.

(e le list comprehension, e soprattutto i sequence object, sono un'idea fottutamente geniale)

Mah non lo so. Credo che dovrò farmele piacere perché l'hanno implementato in JS 1.7. Ma secondo me hanno una sintassi poco piacevole (certo se devi fare cose semplici sono comodissime. Ma se ne abusi... un po' come gli operatori ternari a? b: c? d : e? f? c: d : e)

Perché non dovrebbero esserlo? Tutto in Python è case sensitive.

Ok, se proprio devi allora non mi mettere True e False... mettimi true e false, o TRUE e FALSE. Ma va beh, forse mi ci sono scontrato a causa del fatto che in tutti i linguaggi ho sempre scritto "true" o "false".

Se non è bella la sintassi Python non so cosa si può dire di PHP, Perl, C++, bash, ...

Infatti nessuno è così pazzo da dire che PHP o Perl o C++ abbiano una sintassi bella.
Il fatto è che lo sentivo dire spesso di python. Poi quando ho fatto un paio di settimane di full immersion, la mia percezione non coincideva per nulla con quello che sentivo dire in giro. Eh si che ho programmato sia in js che php, C#, Java e actionscript 2 e 3... quindi sono abbastanza aperto a nuovi orizzonti.

Poi dai.. mancano le costanti, e pure lo switch.

Se devo sceglierne uno... sceglierei ActionScript 3.0. Secondo me è il migliore a livello di chiarezza. (parlo semplicemente del linguaggio, non di tutto quello che c'è attorno). Ma non ha senso impararlo oggi.

[MItaly]

Secondo me i casi sono troppi e troppo vari per imporre una regola così forte. Allunghi le linee di codice anche quando non è necessario. Per me deve rimanere una buona pratica e non una imposizione.

Non sono d'accordo. In qualunque altro linguaggio ho sempre scritto codice indentato, perché senza non si capisce una sega. Se il codice inizia ad essere troppo indentato, vuol dire che è arrivato il momento di un refactoring. Inoltre, Python non ti impone un numero di spazi fisso: volendo puoi indentare anche ad uno spazio, se esci dalle canoniche 80 colonne con indentazione di 'sto tipo vuol dire che stai facendo qualcosa di decisamente sbagliato.

Mah non lo so. Credo che dovrò farmele piacere perché l'hanno implementato in JS 1.7. Ma secondo me hanno una sintassi poco piacevole (certo se devi fare cose semplici sono comodissime. Ma se ne abusi... un po' come gli operatori ternari a? b: c? d : e? f? c: d : e)

Be', questo vale per qualunque caratteristica "avanzata" del linguaggio; ma fidati che in genere sono di una comodità estrema, a patto appunto di non abusarne.

Ok, se proprio devi allora non mi mettere True e False... mettimi true e false, o TRUE e FALSE. Ma va beh, forse mi ci sono scontrato a causa del fatto che in tutti i linguaggi ho sempre scritto "true" o "false".

Questo ogni tanto turba anche me quando vengo dal C++.

Poi dai.. mancano le costanti, e pure lo switch.

Le costanti in un linguaggio dinamico come Python non servono a niente. Lo switch ogni tanto manca anche a me, anche se in genere si rimpiazza o con una (brutta) catena di elif o con un dictionary (che poi è di fatto come spesso vengono implementati gli switch "sotto il cofano"). Sulla questione comunque si è discusso a lungo.

[chumkiu]

Non sono d'accordo. In qualunque altro linguaggio ho sempre scritto codice indentato, perché senza non si capisce una sega.

if(a) print("a");
if(b) print("b");
if(c) print("c");
if(d) print("d");
if(e) print("e");

lo reputo più chiaro e conciso di

if a :
	print "a"
if b :
	print "b"
if c :
	print "c"
if d :
	print "d"
if e :
	print "e"

oppure

print "a" if a else "a"
print "b" if b else "b"
print "c" if c else "c"
print "d" if d else "d"
print "e" if e else "e"

E' solo un esempio. E'il concetto di usare l'indentazione (rientrante nello stile visivo) come definizione di blocco è una cosa che mi fa storcere li naso. Ammetto che nella maggioranza dei casi è un vantaggio per la leggibilità, ma non mi piace essere costretto nell'estetica del sorgente.

Be', questo vale per qualunque caratteristica "avanzata" del linguaggio; ma fidati che in genere sono di una comodità estrema, a patto appunto di non abusarne.

Si, sono d'accordo che sono comode. Un po' ostiche a prima vista ma non tanto quanto le regular expressions.

Le costanti in un linguaggio dinamico come Python non servono a niente.

C'è stata una discussione anche sul PHP (che è il linguaggio su cui sto il 60% del tempo [e non vado in giro a dire che è bello, ma ci convivo ]). Ma la domanda madre è: perché devo usare una variabile per un valore che DEVE essere costante? In ogni caso non è vitale averne.

[MItaly]

if(a) print("a");
if(b) print("b");
if(c) print("c");
if(d) print("d");
if(e) print("e");

In Python è concesso:

if a: print "a"
if b: print "b"
if c: print "c"

Volendo strafare, è anche concesso

if a: print "a"; print "b"

ma non ho mai visto nessuno effettivamente usare la sintassi con il punto e virgola.

C'è stata una discussione anche sul PHP (che è il linguaggio su cui sto il 60% del tempo [e non vado in giro a dire che è bello, ma ci convivo ]).

Ci mancherebbe, PHP è innegabilmente orrido.

Ma la domanda madre è: perché devo usare una variabile per un valore che DEVE essere costante? In ogni caso non è vitale averne.

Anche qui, sono scelte progettuali... credo che dipenda da due fatti fondamentali:

• per l'interprete Python (in cui tutto è dinamico e alla fine tutti gli oggetti sono hashtable) una costante sarebbe un caso inutilmente speciale di variabile;
• l'idea di fondo di Python è "è più facile chiedere scusa che permesso", per cui il linguaggio tende al lassez-faire più completo; per esempio, le classi Python non hanno "veri" membri privati, ma c'è la convenzione per cui i membri "teoricamente da non toccare" hanno il nome che comincia per underscore (ad un certo punto sono stati implementati i nomi con doppio underscore, che funzionano tramite name mangling, ma di rado li ho visti usare).

Questo atteggiamento consente di evitare di dover fare refactoring allucinanti quando salta fuori un singolo caso in cui bisogna violare un'interfaccia, anche se allo stesso tempo bisogna evitare di partorire mostri (in Python 2 è tranquillamente possibile fare

matteo@teokubuntu:~$ python
Python 2.7.5+ (default, Sep 19 2013, 13:48:49) 
[GCC 4.8.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> True=False
>>> print True
False
>>>

- ma non significa che uno debba farlo )