Python e paradigma di programmazione ad oggetti...

[astruso83]

Salve,
Ho capito che i linguaggi di programmazione permettono paradigmi (stili) di programmazione diversi (funzionale, procedurale, ad oggetti, ecc.)

Per esempio, con Python si puo' programmare in modi diversi mentre in Java, penso, il paradigma OOP e' l'unica scelta possibile. C non permette invece di programmare OOP mentre C++ e' ibrido come Python permettendo OOP e anche solamente procedurale.

Nel caso di Python, che sto imparando, e' senz'altro possibile programmare nel modo procedurale classico ma si puo' anche usare il paradigma OOP creando classi, istanze, ecc.Questo mi fa pensare che Python non sia appunto legato al paradigma OOP come non lo e' a quello procedurale...
Domanda: se Python non e' intrinsicamente legato a OOP, perche' allora ogni elemento (lista, variabile, stringa) e' visto come un oggetto? Tutto (variabili, funzioni, moduli, etc.) e' interpretato come un oggetto...Significa che sotto sotto Python e' orientato agli oggetti derivanti da classi predefinite anche quando non si programma creando classi, ecc?

Esempio:
a= [2,3,4]
type(a) # ci dice da che la lista a e' un oggetto derivante dalla classe list

Grazie!

[Quinzio]

Guarda, chiariamo subito un concetto di base: su questo argomento ci sarebbe da parlarne per giorni e giorni.
Inoltre non stiamo parlando di definizioni rigorose e ci sono anche delle correnti di pensiero discordanti.
Poi mi sembra di capire che sei agli inizi e pertanto il tuo obbiettivo adesso e' quello di "sapere utilizzare" Python, anche senza capire completamente perche' quello che fai funziona e siccome non abbiamo e non vogliamo parlarne per giorni e giorni (ma si e' sempre liberi di farlo se si vuole), cerchero' di rispondere almeno alle due domande che hai posto.

se Python non e' intrinsicamente legato a OOP, perche' allora ogni elemento (lista, variabile, stringa) e' visto come un oggetto?

Ci sono 2 motivi, fondamentalmente.
1) Python e' un linguaggio interpretato e non compilato (anche questo non e' completamente vero). Quindi, quando lanci un programma in Python, l'interprete mette a disposizione una grossa infrastruttura di librerie e funzioni. Infatti sarebbe piu' corretto parlare di script in Python. Il vero programma e' Python stesso, il quale esegue il tuo script.
2) Il vero motivo, forse, e' piu' semplice. Si vuole che sia cosi'. Ovvero Python e' stato creato con l'idea di semplificare il piu' possibile la vita al programmatore, anche ai meno esperti. Un modo di fare cio' e' quello di fare in modo che ogni "oggetto" sia un... oggetto. Ovvero anche interi e array di interi sono creati come oggetti. Si vuole che sia cosi' e l'interprete mette a disposizione il marchingegno necessario.

Significa che sotto sotto Python e' orientato agli oggetti derivanti da classi predefinite anche quando non si programma creando classi, ecc?

L'idea e' quella che hai detto, ma cosi' come l'hai scritta non mi sembra proprio corretta.
Diciamo che con Python sei costretto ad usare classi ed oggetti.
A esempio in Java hai ancora accesso ai cosiddetti 'basic types'. In C++ la cosa e' ancora piu' ambigua, siccome il C++ conserva ancora le caratteristiche del C.

Se posso fare un esempio un po' strano, prova a vedere i linguaggi non OOP come un supermercato dove puoi comprare gli alimenti di base e poi sei tu a cucinare i pasti. I linguaggi OOP assomigliano piu' a dei ristoranti, dove i piatti vengono serviti pronti e gli ingredienti base non sono accessibili. In un ristorante non puoi entrare e chiedere un bicchiere d'acqua, o almeno, nessuno lo fa, perche' non e' il posto adatto. In un ristorante servono anche l'acqua, ma e' un elemento del menu, e di solito viene servita e accompagnata da altri piatti molto elaborati.

Va beh, credo che sia sufficiente cosi, altrimenti c'e' il rischio che le idee si confondano solo di piu'.

[astruso83]

Grazie per l'assistenza Quinzio,

E' vero:
a) sono un principiante in materia
b) meglio che mi focalizzi sull'utilizzo anche se la curiosita' di capire certe cose sottili e' tanta

Le tue risposte sono chiare.

In merito a Python/interprete/compilatore: come Java, Python non e' puramente interpretato ma viene prima compilato, cioe' il codice sorgente Python viene transformato in bytecode che non e' linguaggio macchina puro ma piu' vicino ad esso (un po' come il linguaggio assemblato).
Il bytecode viene poi digerito da una macchina virtuale... L'interprete di Python comprende quindi, da quello che ho capito, sia un compilatore (fase 1) sia la macchina virtuale (fase 2) che non e' altro che un programma che comunica con il sistema operativo e la CPU.

Si dice che Python sia piu' portabile rispetto al C. Nel caso del C, il codice sorgente viene compilato tutto in un colpo in un codice macchina specifico per la piattaforma (sistema operativo+CPU). Quindi, nel caso si voglia distribuire un codice in C, c'e' meno portabilita' a meno che ogni macchina abbia il compilatore C per tradurre il codice sorgente C. Allora tutto funziona come deve...

Nel caso di Python, macchine con piattaforme diverse dovranno pero' avere macchine virtuali diverse e specifiche al sistema....Quello che e' portabile e' il bytecode, direi. Ho capito correttamente?

Eppure sia in C sia in Python e' necessario avere un software (compilatore in C e macchina virituale in Python) che dipende dalla piattaforma specifica. Python viene pero' definito come piu' portabile del C nonstante piattaforme diverse richiedano comunque macchine virtuali diverse...Non c'e' una macchina virtuale universale che funziona su tutte le piattaforme...

Grazie!

[apatriarca]

In merito a Python/interprete/compilatore: come Java, Python non e' puramente interpretato ma viene prima compilato, cioe' il codice sorgente Python viene transformato in bytecode che non e' linguaggio macchina puro ma piu' vicino ad esso (un po' come il linguaggio assemblato).
Il bytecode viene poi digerito da una macchina virtuale... L'interprete di Python comprende quindi, da quello che ho capito, sia un compilatore (fase 1) sia la macchina virtuale (fase 2) che non e' altro che un programma che comunica con il sistema operativo e la CPU.

Non credo abbia senso parlare di linguaggi interpretati e compilati ormai. Prima di tutto perché un linguaggio può disporre di numerosi compilatori/interpreti su cui basarsi. Per Python c'è ovviamente CPython, ma anche progetti come Pypy, Numba, Pyjion, Jython, IronPython... e modi per creare eseguibili. Per il C ci sono gcc, clang, msvc, tcc, ch... (gli ultimi due permettono di eseguire sorgenti C come degli script). Dopodiché spesso anche gli stessi linguaggi usando lo stesso compilatore/interprete possono essere eseguiti in modi diversi. Ecco quindi linguaggi come Python che normalmente vengono eseguiti come script che permettono di essere compilati in un formato intermedio (di solito non un eseguibile) e linguaggi normalmente compilati che possono essere eseguiti direttamente dal codice sorgente.

La macchina virtuale non ha comunque lo scopo di comunicare con il sistema operativo e la CPU. Ha lo scopo di eseguire le istruzioni del bytecode il più velocemente possibile. È in pratica un enorme switch che a ogni istruzione del bytecode associa la corrispondente operazione (per esempio sommare due valori o accedere a una variabile membro della tua classe).

Sinceramente comunque la principale ragione per cui in Python tutto deriva da object è storica e non credo sia sempre stato così. In effetti quando ho iniziato a usare Python era necessario far dipendere le nuove classi da object in modo esplicito e le funzionalità OOP erano un po' mal organizzate. Di fatto in Python qualsiasi cosa è più che altro un dizionario/mappa. Un altro aspetto importante è inoltre il fatto di fare uso della tipizzazione dinamica per cui è in qualche nodo necessario avere un'interfaccia standard per poter accedere a ogni tipo di variabile. Se incontri infatti qualcosa come "a + b" in C sai esattamente quali sono i tipi di a e b e il significato della somma. In Python il tipo lo conosci solo a runtime per cui in realtà sta eseguendo un metodo chiamato "__add__" di a che verificherà probabilmente il tipo di "b" per decidere se può fare questa operazione e in cosa consiste. Ovviamente in pratica per i tipi primitivi non fa davvero una chiamata a una funzione (se non dentro all'interprete stesso).

Si dice che Python sia piu' portabile rispetto al C. Nel caso del C, il codice sorgente viene compilato tutto in un colpo in un codice macchina specifico per la piattaforma (sistema operativo+CPU). Quindi, nel caso si voglia distribuire un codice in C, c'e' meno portabilita' a meno che ogni macchina abbia il compilatore C per tradurre il codice sorgente C. Allora tutto funziona come deve...

Nel caso di Python, macchine con piattaforme diverse dovranno pero' avere macchine virtuali diverse e specifiche al sistema....Quello che e' portabile e' il bytecode, direi. Ho capito correttamente?

Eppure sia in C sia in Python e' necessario avere un software (compilatore in C e macchina virituale in Python) che dipende dalla piattaforma specifica. Python viene pero' definito come piu' portabile del C nonstante piattaforme diverse richiedano comunque macchine virtuali diverse...Non c'e' una macchina virtuale universale che funziona su tutte le piattaforme...

Grazie!

Quella della poca portabilità del C è un'invenzione propagandistica portata avanti da Java per vendere l'idea della sua JVM. L'idea è quella di considerare la portabilità di quello che viene eseguito (il bytecode di Java o lo script Python) piuttosto che il codice C. Il problema è in realtà che ci sono spesso molte differenze tra i diversi sistemi anche a livello di Python o Java per cui la portabilità dell'eseguibile è spesso più teorica che pratica. Se vediamo la portabilità in termini di codice sorgente allora il C ha sicuramente la maggiore portabilità di ogni linguaggio di programmazione perché in pratica non esiste alcuna macchina che non abbia un compilatore C (e qui parlo anche di microcontrollori anche molto limitati che non sono in grado di far girare Python o Java).