Il 20 febbraio 1991 Guido van Rossum pubblic\u00f2 nel gruppo alt.sources il primo rilascio del linguaggio di programmazione Python, su cui aveva lavorato dal dicembre 1989 come parte di un progetto per creare un linguaggio di scripting per la risoluzione di problemi di amministrazione di sistema nel sistema operativo Amoeba, che fosse di livello superiore rispetto a C, ma, a differenza della Bourne shell, fornisse un accesso pi\u00f9 comodo alle syscall del sistema operativo. <\/p>\n
Il nome del progetto \u00e8 stato scelto in onore della troupe comica Monty Python. Nella prima versione, \u00e8 stata implementata la supporto per classi con ereditariet\u00e0, gestione delle eccezioni, un sistema di moduli e i tipi fondamentali list, dict e str. L'implementazione di moduli ed eccezioni \u00e8 stata presa dal linguaggio Modula-3, mentre lo stile di codifica basato sugli spazi \u00e8 stato tratto dal linguaggio ABC, a cui Guido aveva precedentemente partecipato allo sviluppo. <\/p>\n
Nel processo di creazione di Python, Guido si \u00e8 attenuto ai seguenti principi: <\/p>\n
\n
Principi che hanno permesso di risparmiare tempo nello sviluppo:\n
\n
Prendere idee utili da altri progetti.\n
Una ricerca della semplicit\u00e0, senza eccessiva semplificazione (il principio di Einstein: \u00abTutto deve essere spiegato il pi\u00f9 semplicemente possibile, ma non pi\u00f9 semplice\u00bb).\n
Seguire la filosofia UNUX, secondo cui i programmi realizzano una singola funzionalit\u00e0, ma la fanno bene.\n
Non preoccuparsi eccessivamente delle prestazioni; le ottimizzazioni possono essere aggiunte se necessario, quando si rendono necessarie.\n
Non cercare di combattere le situazioni esistenti, ma seguire il flusso.\n
Evitare il perfezionismo; di solito \u00e8 sufficiente un livello di \u00ababbastanza buono\u00bb.\n
A volte \u00e8 possibile fare dei compromessi, specialmente se qualcosa pu\u00f2 essere fatto in un secondo momento. <\/ul>\n
Principi aggiuntivi:\n
\n
L'implementazione non deve essere vincolata a una piattaforma specifica. Alcune funzionalit\u00e0 potrebbero non essere sempre disponibili, ma la funzionalit\u00e0 di base deve funzionare ovunque.\n
Non sovraccaricare gli utenti con dettagli che possono essere gestiti dalla macchina.\n
Supportare e promuovere codice dell'utente indipendente dalla piattaforma, senza limitare l'accesso alle funzionalit\u00e0 e alle peculiarit\u00e0 della piattaforma.\n
Grandi sistemi complessi devono fornire diversi livelli di estensibilit\u00e0.\n
Gli errori non devono essere fatali e invisibili \u2014 il codice dell'utente deve poter intercettare e gestire gli errori.\n
Gli errori nel codice dell'utente non devono influenzare la funzionalit\u00e0 della macchina virtuale e non devono portare a comportamenti indesiderati dell'interprete e a crash dei processi. <\/ul>\n