it-swarm.it

Quali sono gli svantaggi di Python?

Python sembra essere di gran moda in questi giorni, e non immeritatamente, perché è davvero un linguaggio con il quale quasi si diverte a ricevere un nuovo problema da risolvere. Ma, come disse una volta omo saggio (chiamandolo omo saggio solo perché non ho idea di chi l'abbia effettivamente detto; non so se fosse così saggio tutto), per conoscere veramente un linguaggio non si conoscono solo i vantaggi della sintassi, del design, ecc., ma anche i suoi svantaggi. Nessuna lingua è perfetta, alcune sono semplicemente migliori di altre.

Quindi, quale sarebbe secondo te, gli svantaggi oggettivi di Python.

Nota: non sto chiedendo un confronto linguistico qui (cioè C # è meglio di Python perché ... yadda yadda yadda) - più di un obiettivo (a un certo livello) opinione su quali caratteristiche del linguaggio sono mal progettate, se, quali sono forse alcuni che ti mancano e così via. Se si deve usare un'altra lingua come confronto, ma solo per illustrare un punto che sarebbe difficile da elaborare altrimenti (cioè per facilità di comprensione)

147
Rook

Uso Python in qualche modo regolarmente, e nel complesso lo considero un linguaggio molto buono. Tuttavia, nessun linguaggio è perfetto. Ecco gli svantaggi in ordine di importanza per me personalmente:

  1. È lento. Intendo davvero, molto lentamente. Molte volte questo non ha importanza, ma significa sicuramente che avrai bisogno di un'altra lingua per quei bit critici per le prestazioni.

  2. Le funzioni nidificate in qualche modo risucchiano dal fatto che non è possibile modificare le variabili nell'ambito esterno. Modifica: Uso ancora Python 2 a causa del supporto della libreria, e questo difetto di progettazione mi irrita molto, ma apparentemente è stato corretto in Python 3 a causa dell'istruzione nonlocale . Non vedo l'ora che le librerie che uso vengano portate in modo che questo difetto possa essere inviato in cenere mucchio di storia per sempre.

  3. Manca alcune funzionalità che possono essere utili per la libreria/codice generico e IMHO sono semplicità portata agli estremi malsani. I più importanti che mi vengono in mente sono tipi di valore definiti dall'utente (suppongo che questi possano essere creati con la magia della metaclasse, ma non ho mai provato) e il parametro della funzione ref.

  4. È lontano dal metallo. Devi scrivere threading primitive o codice del kernel o qualcosa del genere? In bocca al lupo.

  5. Anche se non mi dispiace la mancanza di capacità di rilevare errori semantici in anticipo come compromesso per il dinamismo che Python offre, vorrei che ci fosse un modo per catturare errori sintattici e cose stupide come errori di digitazione dei nomi delle variabili senza dover eseguire effettivamente il codice.

  6. La documentazione non è buona come lingue come PHP e Java che hanno solidi supporti aziendali.

109
dsimcha

Odio che Python non è in grado di distinguere tra dichiarazione e utilizzo di una variabile. Non è necessario digitare staticamente per farlo accadere. Sarebbe solo bello avere un modo per dire "questo è una variabile che dichiaro deliberatamente e io intendo per introdurre un nuovo nome, questo non è un errore di battitura ”.

Inoltre, di solito uso Python variabili in uno stile write-once, cioè considero le variabili come immutabili e non le modifico dopo il loro primo assegnamento. Grazie a funzionalità come la comprensione dell'elenco , questo è incredibilmente facile e rende il flusso del codice più facile da seguire.

Tuttavia, non posso documentare questo fatto. Niente in Python mi impedisce di sovrascrivere o riutilizzare le variabili.

In sintesi, vorrei avere due parole chiave nella lingua: var e let. Se scrivo su una variabile non dichiarata da nessuna di queste, Python dovrebbe generare un errore. Inoltre, let dichiara le variabili come di sola lettura, mentre var le variabili sono "normali".

Considera questo esempio:

x = 42    # Error: Variable `x` undeclared

var x = 1 # OK: Declares `x` and assigns a value.
x = 42    # OK: `x` is declared and mutable.

var x = 2 # Error: Redeclaration of existing variable `x`

let y     # Error: Declaration of read-only variable `y` without value
let y = 5 # OK: Declares `y` as read-only and assigns a value.

y = 23    # Error: Variable `y` is read-only

Si noti che i tipi sono ancora impliciti (ma le variabili let sono a tutti gli effetti tipizzate staticamente poiché non possono essere rimbalzate su un nuovo valore, mentre le variabili var possono ancora essere tipizzate dinamicamente).

Infine, tutti gli argomenti del metodo dovrebbero automaticamente essere let, cioè dovrebbero essere di sola lettura. In generale, non esiste alcun motivo valido per modificare un parametro, ad eccezione del seguente linguaggio:

def foo(bar = None):
    if bar == None: bar = [1, 2, 3]

Questo potrebbe essere sostituito da un linguaggio leggermente diverso:

def foo(bar = None):
    let mybar = bar or [1, 2, 3]
66
Konrad Rudolph

La mia lamentela principale è il threading, che non è altrettanto performante in molte circostanze (rispetto a Java, C e altri) a causa del blocco dell'interprete globale (vedi "Inside the Python GIL" (Collegamento PDF) talk)

Tuttavia c'è un interfaccia multiprocesso che è molto facile da usare, tuttavia sarà più pesante sull'uso della memoria per lo stesso numero di processi rispetto ai thread, o difficile se hai molti dati condivisi . Il vantaggio, tuttavia, è che una volta che un programma funziona con più processi, può ridimensionarsi su più macchine, cosa che un programma thread non può fare.

Non sono affatto d'accordo sulla critica della documentazione, penso che sia eccellente e migliore della maggior parte se non tutte le principali lingue là fuori.

Inoltre è possibile rilevare molti dei bug di runtime che eseguono pylint .

44
cmcginty

Probabilmente, la mancanza di tipizzazione statica, che può introdurre alcune classi di errori runtime, non vale la flessibilità aggiuntiva fornita dalla tipizzazione duck.

28
Jacob

Penso che le parti orientate agli oggetti di Python siano un po '"imbullonate". L'intero bisogno di passare esplicitamente "sé" a ogni metodo è un sintomo del fatto che il componente OOP non era espressamente pianificato , si potrebbe dire; mostra anche le regole di scoping a volte verrucose di Python che sono state criticate in un'altra risposta.

Edit:

Quando dico che le parti orientate agli oggetti di Python sembrano "imbullonate", intendo a volte che il lato OOP sembra piuttosto incoerente. Prendi Ruby, per esempio: in Ruby, tutto è un oggetto e chiami un metodo usando la familiare sintassi obj.method (Ad eccezione di operatori sovraccarichi, di corso); in Python, anche tutto è un oggetto, ma alcuni metodi che chiami come una funzione; cioè, sovraccarichi __len__ per restituire una lunghezza, ma chiamalo usando len(obj) invece del più familiare (e coerente) obj.length comune in altre lingue. So che ci sono ragioni dietro questa decisione di progettazione, ma non mi piacciono.

Inoltre, il modello OOP di Python non ha alcun tipo di protezione dei dati, vale a dire che non ci sono membri privati, protetti e pubblici; puoi imitarli usando _ e __ davanti ai metodi, ma è un po 'brutto. Allo stesso modo, Python non riesce abbastanza a ottenere l'aspetto di passaggio dei messaggi di OOP giusto.

27
mipadi

Le cose che non mi piacciono di Python:

  1. Threading (so che è già stato menzionato, ma vale la pena menzionarlo in ogni post).
  2. Nessun supporto per funzioni anonime su più righe (lambda può contenere solo un'espressione).
  3. Mancanza di una funzione/classe di lettura input semplice ma potente (come cin o scanf in C++ e C o Scanner in Java).
  4. Tutte le stringhe non sono Unicode per impostazione predefinita (ma corrette in Python 3).
19
MAK

Argomenti predefiniti con tipi di dati modificabili.

def foo(a, L = []):
    L.append(a)
    print L

>>> foo(1)
[1]
>>> foo(2)
[1, 2]

Di solito è il risultato di alcuni bug sottili. Penso che sarebbe meglio se creasse un nuovo oggetto elenco ogni volta che era richiesto un argomento predefinito (piuttosto che creare un singolo oggetto da usare per ogni chiamata di funzione).

Modifica: non è un grosso problema, ma quando è necessario fare riferimento a qualcosa nei documenti, significa comunemente che è un problema. Questo non dovrebbe essere richiesto.

def foo(a, L = None):
    if L is None:
        L = []
    ...

Soprattutto quando avrebbe dovuto essere l'impostazione predefinita. È solo uno strano comportamento che non corrisponde a quello che ti aspetteresti e non è utile per un gran numero di circostanze.

18
jsternberg

Alcune delle funzionalità di Python che lo rendono così flessibile come linguaggio di sviluppo sono anche viste come importanti svantaggi per chi è abituato all'analisi statica "dell'intero programma" condotta dal processo di compilazione e collegamento in linguaggi come C++ e Java.

  • Dichiarazione implicita di variabili locali

Le variabili locali vengono dichiarate utilizzando la normale istruzione di assegnazione. Ciò significa che i collegamenti variabili in qualsiasi altro ambito richiedono che il compilatore raccolga annotazioni esplicite (dichiarazioni globali e non locali per ambiti esterni, notazione di accesso agli attributi per ambiti di istanza). Ciò riduce enormemente la quantità di boilerplate necessaria durante la programmazione, ma significa che sono necessari strumenti di analisi statica di terze parti (come pyflakes) per eseguire controlli gestiti dal compilatore in linguaggi che richiedono dichiarazioni di variabili esplicite.

  • "Monkey patching" è supportato

Il contenuto di moduli, oggetti di classe e persino lo spazio dei nomi incorporato può essere modificato in fase di esecuzione. Questo è estremamente potente, consentendo molte tecniche estremamente utili. Tuttavia, questa flessibilità significa che Python non offre alcune funzionalità comuni alle lingue OO tipizzate staticamente. In particolare, il parametro "self" per i metodi di istanza è esplicito piuttosto che implicito (poiché i "metodi" non devono essere definiti all'interno di una classe, possono essere aggiunti in seguito modificando la classe, il che significa che non è particolarmente pratico per passare implicitamente il riferimento all'istanza) e i controlli di accesso agli attributi non possono essere facilmente applicati in base al fatto che il codice sia "dentro" o "fuori" dalla classe (poiché tale distinzione esiste solo mentre la definizione della classe è in esecuzione).

  • Lontano dal metallo

Ciò vale anche per molti altri linguaggi di alto livello, ma Python tende a sottrarre la maggior parte dei dettagli hardware. I linguaggi di programmazione di sistemi come C e C++ sono ancora molto più adatti alla gestione dell'accesso diretto all'hardware (tuttavia, Python parlerà abbastanza felicemente a quelli tramite i moduli di estensione CPython o, più facilmente, tramite ctypes biblioteca).

14
ncoghlan
  1. Uso del rientro per i blocchi di codice anziché {}/begin-end, qualunque cosa.
  2. Ogni linguaggio moderno più recente ha un corretto ambito lessicale, ma non Python (vedi sotto).
  3. Documenti caotici (confronta con la documentazione Perl5, che è superba).
  4. Giacca dello stretto (c'è solo un modo per farlo).

Esempio di scoping rotto; trascrizione dalla sessione dell'interprete:

>>> x=0
>>> def f():
...     x+=3
...     print x
... 
>>> f()
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment

global e nonlocal sono state introdotte parole chiave per correggere questa stupidità progettuale.

12
zvrba

Trovo la combinazione di python di this.method() orientata agli oggetti e procedurale/funzionale method(this) sintassi molto inquietante:

x = [0, 1, 2, 3, 4]
x.count(1)
len(x)
any(x)
x.reverse()
reversed(x)
x.sort()
sorted(x)

Ciò è particolarmente negativo perché un gran numero di funzioni (piuttosto che metodi) sono appena scaricate nello spazio dei nomi globale : metodi relativi a liste, stringhe, numeri, costruttori, metaprogrammazione, tutti mescolati in un unico grande elenco in ordine alfabetico.

Per lo meno, i linguaggi funzionali come F # hanno tutte le funzioni opportunamente spaziate nei moduli:

List.map(x)
List.reversed(x)
List.any(x)

Quindi non sono tutti insieme. Inoltre, questo è uno standard seguito in tutta la biblioteca, quindi almeno è coerente.

Comprendo i motivi per eseguire la funzione funzione vs metodo , ma i penso ancora che sia una cattiva idea mescolarli in questo modo. Sarei molto più felice se fosse seguita la sintassi del metodo, almeno per le operazioni comuni:

x.count(1)
x.len()
x.any()
x.reverse()
x.reversed()
x.sort()
x.sorted()

Indipendentemente dal fatto che i metodi stiano mutando o meno, averli come metodi sull'oggetto presenta diversi vantaggi:

  • Posto unico per cercare le operazioni "comuni" su un tipo di dati: altre librerie/ecc. possono avere altre cose fantasiose che possono fare ai tipi di dati ma le operazioni "predefinite" sono tutte nei metodi dell'oggetto.
  • Non è necessario continuare a ripetere Module quando si chiama Module.method(x). Prendendo l'esempio di Elenco funzionale sopra, perché devo continuare a ripetere List? Dovrebbe sapere che è una List e non voglio chiamare la funzione Navigation.map() su di essa! L'uso della sintassi x.map() lo mantiene DRY e ancora non ambiguo.

E ovviamente ha dei vantaggi rispetto al modo put-everything-in-global-namespace di farlo. Non è che il modo attuale sia incapace di fare le cose. È anche piuttosto conciso (len(lst)), dal momento che nulla è spaziato! Comprendo i vantaggi nell'uso delle funzioni (comportamento predefinito, ecc.) Rispetto ai metodi, ma ancora non mi piace.

È solo disordinato. E nei grandi progetti, la confusione è il tuo peggior nemico.

11
Haoyi

Mancanza di omoiconicità .

Python ha dovuto attendere 3.x per aggiungere una parola chiave "with". In qualsiasi linguaggio omoiconico avrebbe potuto essere banalmente aggiunto in una biblioteca.

La maggior parte degli altri problemi che ho visto nelle risposte sono di 3 tipi:

1) Cose che possono essere riparate con gli strumenti (ad esempio pyflakes) 2) Dettagli di implementazione (GIL, prestazioni) 3) Cose che possono essere riparate con standard di codifica (cioè caratteristiche che le persone vorrebbero non esistere)

# 2 non è un problema con la lingua, IMO # 1 e # 3 non sono problemi seri.

8
Jason

Python è la mia lingua preferita in quanto è molto espressivo, ma ti impedisce ancora di fare troppi errori. Ho ancora alcune cose che mi infastidiscono:

  • Nessuna vera funzione anonima. Lambda può essere utilizzato per le funzioni a singola istruzione e l'istruzione with può essere utilizzata per molte cose in cui useresti un blocco di codice in Ruby. Ma in alcune situazioni rende le cose un po 'più goffe di quanto dovrebbero essere. (Lungi dall'essere goffo come sarebbe in Java, ma comunque ...)

  • Qualche confusione nella relazione tra moduli e file. L'esecuzione di "python foo.py" dalla riga di comando è diversa da "import foo". Importazioni relative in Python 2.x può anche causare problemi. Tuttavia, i moduli di Python sono molto meglio delle corrispondenti funzionalità di C, C++ e Ruby.

  • Esplicito self. Anche se capisco alcune delle ragioni di ciò, e anche se uso Python ogni giorno, tendo a commettere l'errore di dimenticarlo. Un altro problema è che diventa un po 'noioso creare una classe da un modulo. Il sé esplicito è legato al limitato ambito di cui altri si sono lamentati. L'ambito più piccolo in Python è l'ambito della funzione. Se mantieni le tue funzioni piccole, come dovrebbe, questo non è un problema da solo e l'IMO spesso fornisce un codice più pulito.

  • Alcune funzioni globali, come len, che ti aspetteresti di essere un metodo (che in realtà è dietro le quinte).

  • Rientro significativo. Non l'idea stessa, che penso sia grandiosa, ma poiché questa è l'unica cosa che impedisce a così tante persone di provare Python, forse Python sarebbe meglio con qualche inizio (fine) (opzionale) simboli. Ignorando quelle persone, potrei vivere totalmente con una dimensione forzata anche per il rientro.

  • Che non è la lingua integrata dei browser Web, anziché JavaScript.

Di questi reclami, è solo il primo a cui tengo abbastanza da pensare che debba essere aggiunto alla lingua. Gli altri sono piuttosto minori, tranne l'ultimo, il che sarebbe fantastico se fosse successo!

7
Martin Vilcans

Python non è completamente maturo: il linguaggio python 3.2 in questo momento ha problemi di compatibilità con la maggior parte dei pacchetti attualmente distribuiti (in genere sono compatibili con python 2.5) Questo è un grosso svantaggio che attualmente richiede maggiori sforzi di sviluppo (trova il pacchetto necessario; verifica la compatibilità; sopporta la scelta di un pacchetto non buono che potrebbe essere più compatibile; prendi la versione migliore, aggiornala alla 3.2 che potrebbe richiedere giorni; poi inizia a fare qualcosa di utile).

Probabilmente a metà 2012 questo sarà meno di uno svantaggio.

Nota che credo di essere stato sottratto da un fan-boy. Durante una discussione con gli sviluppatori, il nostro team di sviluppatori di alto livello ha raggiunto la stessa conclusione.

La maturità in un senso principale significa che un team può usare la tecnologia ed essere subito operativo senza rischi nascosti (inclusi problemi di compatibilità). Terze parti python e molte app non funziona sotto 3.2 per la maggior parte dei pacchetti oggi. Questo crea più lavoro di integrazione, test, reimplementazione della tecnologia stessa invece di risolvere il problema attuale == tecnologia meno matura.

Aggiornamento per giugno 2013: Python 3 presenta ancora problemi di maturità. Ogni tanto un membro del team menziona un pacchetto necessario quindi dice "tranne che è solo per 2.6" (in alcuni di questi casi io ' abbiamo implementato una soluzione alternativa tramite il socket localhost per utilizzare il pacchetto solo 2.6 con 2.6 e il resto dei nostri strumenti rimane con 3.2). Neanche MoinMoin, il wiki di pure-python, è scritto in Python = 3.

5

L'ambito di Python è gravemente rotto, il che rende la programmazione orientata agli oggetti in Python molto imbarazzante.

4
Mason Wheeler

I modificatori di accesso in Python non sono esecutivi - rende difficile scrivere codice ben strutturato e modularizzato.

Suppongo che faccia parte del campo di applicazione rotto di @ Mason - un grosso problema in generale con questo linguaggio. Per il codice che dovrebbe essere leggibile, sembra abbastanza difficile capire cosa può e dovrebbe essere nell'ambito e quale valore sarà in un dato momento - Sto attualmente pensando di passare dal Python lingua a causa di questi inconvenienti.

Solo perché "siamo tutti adulti consenzienti" non significa che non commettiamo errori e non lavoriamo meglio all'interno di una struttura solida, specialmente quando si lavora su progetti complessi - il rientro e i caratteri di sottolineatura insignificanti non sembrano essere sufficienti .

4
Vector

Le mie lamentele su Python:

  • Bolted-on OOP (Vedi la risposta di @ mipadi per l'elaborazione al riguardo)
  • Implementazione non corretta di lambda
  • Problemi di portata
  • Nessuna raccolta persistente nella libreria standard
  • Scarsa amabilità ai DSL integrati
4
missingfaktor

La spedizione multipla non si integra bene con il sistema di tipo a spedizione singola stabilito e non è molto performante.

Il caricamento dinamico è un grosso problema su file system paralleli in cui la semantica simile a POSIX porta a rallentamenti catastrofici per operazioni ad alta intensità di metadati. Ho colleghi che hanno bruciato un quarto di milione di core-hour ottenendo Python (con numpy, mpi4py, petsc4py e altri moduli di estensione) caricati su core da 65k. (La simulazione ha prodotto una significativa nuova scienza risultati, quindi ne è valsa la pena, ma è un problema quando viene bruciato più di un barile di petrolio per caricare Python una volta.) L'incapacità di collegarsi staticamente ci ha costretti a fare grandi contorsioni a ottenere tempi di caricamento ragionevoli su larga scala, inclusa l'applicazione di patch a libc-rtld per fare in modo che dlopen esegua l'accesso al file system collettivo.

3
Jed
  • un bel po 'di librerie e software di terze parti molto diffusi che sono ampiamente usati, non sono abbastanza Pythonic. Alcuni esempi: soaplib, openerp, reportlab. La critica è fuori portata, è lì, è ampiamente usata, ma rende confusa la cultura python (fa male il motto che dice "Dovrebbe essercene uno - e preferibilmente solo uno - -oprovabile modo di farlo "). I successi noti di Pythonic (come Django o trac) sembrano essere l'eccezione.
  • la profondità potenzialmente illimitata di astrazione di istanza, classe, metaclasse è concettualmente bella e unica. Ma per padroneggiarlo devi conoscere profondamente l'interprete (in cui l'ordine python viene interpretato, ecc.). Non è ampiamente conosciuto e usato (o usato correttamente), mentre simile magia nera simile come generici C #, che è concettualmente più contorto (IMHO) sembra più ampiamente conosciuto e usato, proporzionalmente.
  • per avere una buona conoscenza della memoria e del modello di threading, devi avere abbastanza esperienza con Python, perché non ci sono specifiche complete. Sai solo cosa funziona, forse perché hai letto le fonti dell'interprete o sperimentato stranezze e hai scoperto come risolverle. Ad esempio, ci sono solo riferimenti forti o deboli, non i riferimenti soft e fantasma di Java. Java ha un thread per la garbage collection mentre non c'è una risposta formale su quando avviene la garbage collection in python; puoi semplicemente osservare che la garbage collection non avviene se no python viene eseguito e concludere che a volte succede probabilmente quando si tenta di allocare memoria. Può essere complicato quando non si conosce il motivo per cui non è stata rilasciata una risorsa bloccata (la mia esperienza al riguardo era mod_python in freeswitch).

Comunque, python è la mia lingua principale ormai da 4 anni. Essere fanboys, elitari o monomaniaci non fa parte della cultura python.

3
vincent

Preferisco python e il primo svantaggio che mi viene in mente è quando si commenta un'istruzione come if myTest(): quindi è necessario modificare il rientro dell'intero blocco eseguito che non si vorrebbe non hanno a che fare con C o Java. In effetti in python invece di commentare una clausola if invece ho iniziato a commentarla in questo modo: `if True: #myTest ( ), quindi non dovrò nemmeno modificare il seguente blocco di codice. Poiché Java e C non si basano sul rientro, rende più semplice commentare le istruzioni con C e Java.

3
Niklas
  1. Le prestazioni non sono buone, ma stanno migliorando con pypy,
  2. Il GIL impedisce l'uso del threading per velocizzare il codice (anche se di solito si tratta di un'ottimizzazione prematura),
  3. È utile solo per la programmazione dell'applicazione,

Ma ha alcune grandi funzionalità di riscatto:

  1. È perfetto per RAD,
  2. È facile interfacciarsi con C (e per C incorporare un python),
  3. È molto leggibile,
  4. È facile da imparare,
  5. È ben documentato,
  6. Le batterie sono davvero incluse, la sua libreria standard è enorme e pypi contiene moduli praticamente per tutto,
  7. Ha una comunità sana.
3
dan_waterworth
  • Strano OOP:
    • len(s) fino a __len__(self) e altri "metodi speciali"
    • metodi extra speciali che potrebbero essere derivati ​​da altri metodi speciali (__add__ e __iadd__ per + e +=)
    • self come primo parametro del metodo
    • puoi dimenticare di chiamare il costruttore della classe base
    • nessun modificatore di accesso (privato, protetto ...)
  • nessuna definizione costante
  • nessuna immutabilità per tipi personalizzati
  • GIL
  • scarse prestazioni che portano a un mix di Python e C e problemi con build (ricerca di librerie C, dipendenze della piattaforma ...)
  • cattiva documentazione, specialmente nelle librerie di terze parti
  • incompatibilità tra Python 2.xe 3.x
  • strumenti di analisi del codice scadente (rispetto a ciò che viene offerto per linguaggi tipicamente statici come Java o C #)
2
deamon

"Immutabilità" non è esattamente il suo punto di forza. I numeri, le tuple e le stringhe di AFAIK sono immutabili, tutto il resto (cioè gli oggetti) è mutabile. Confronta quello con linguaggi funzionali come Erlang o Haskell in cui tutto è immutabile (per impostazione predefinita, almeno).

Tuttavia, l'immutabilità brilla davvero con la concorrenza *, che non è anche il punto di forza di Python, quindi almeno è conseguente.

(* = Per i nitpicker: intendo la concorrenza che è almeno parzialmente parallela. Immagino Python è ok con la concorrenza "single-threaded", in cui l'immutabilità non è così importante. (Sì, Appassionati di FP, so che l'immutabilità è ottima anche senza concorrenza.))

0
Kosta

Mi piacerebbe avere costrutti esplicitamente paralleli. Più spesso, quando scrivo un elenco di comprensione come

[ f(x) for x in lots_of_sx ]

Non mi interessa l'ordine in cui gli elementi verranno elaborati. A volte, non mi importa nemmeno in quale ordine vengano restituiti.

Anche se CPython non riesce a farlo bene quando la mia f è puro Python, comportamenti come questo potrebbero essere definiti per altre implementazioni da utilizzare.

0
rbanffy

Python non ha ottimizzazione della coda, principalmente per ragioni filosofiche . Ciò significa che il ricorrere della coda su strutture di grandi dimensioni può costare O(n) memoria (a causa dello stack non necessario che viene mantenuto) e richiederà di riscrivere la ricorsione come un ciclo per ottenere O(1) memoria.

0
a3nm