it-swarm-eu.dev

Jaké jsou nevýhody Pythonu?

Zdá se, že Python je v dnešní době stále vztek, a ne nechtěně - protože je to skutečně jazyk, s nímž si člověk téměř užívá, když mu je dán nový problém k vyřešení. Ale, jak řekl moudrý člověk jednou (volal jej moudrý člověk) pouze proto, že nemám ponětí, kdo to vlastně řekl; nejsem si jistý, zda byl tak moudrý v všichni), opravdu znát jazyk, nezná nejen jeho syntaxi, design atd., výhody, ale také jeho nevýhody. Žádný jazyk není dokonalý, některé jsou prostě lepší než jiné.

Co by podle tebe bylo, objektivní nevýhody Pythonu.

Poznámka: Žádám o jazykové srovnání zde (tj. C # je lepší než Python protože ... yadda yadda yadda) - více cíle (do určité úrovně) názor, které jazykové vlastnosti jsou špatně navrženy, zda, co jsou možná některé, které v něm chybí atd. Pokud musí použít jiný jazyk jako srovnání, ale pouze pro ilustraci bodu, který by jinak bylo obtížné rozpracovat (tj. pro snadné porozumění)

147
Rook

Používám Python poněkud pravidelně, a celkově to považuji za velmi dobrý jazyk. Nicméně žádný jazyk není dokonalý. Zde jsou nevýhody v pořadí důležitosti pro mě osobně:

  1. Je to pomalé. Myslím opravdu, opravdu pomalu. Mnohokrát na tom nezáleží, ale rozhodně to znamená, že budete potřebovat jiný jazyk pro ty výkonně důležité bity.

  2. Vnořené funkce jsou takovým způsobem, že nemůžete modifikovat proměnné ve vnějším oboru. Úpravy: Stále používám Python 2 kvůli podpoře knihovny) a tento design vad dráždí sakra ode mě, ale zjevně je to opraveno v Python 3 kvůli příkazu nonlocal ). Nemůžu se dočkat, až dojde k přenesení libů, které používám, takže tuto chybu lze poslat na popel hromadu historie navždy.

  3. Chybí několik funkcí, které mohou být užitečné pro knihovnu/obecný kód, a IMHO jsou jednoduchostí přeneseny do nezdravých extrémů. Nejdůležitější z nich si myslím, jsou uživatelsky definované typy hodnot (hádám, že je lze vytvořit pomocí magie metaclass, ale nikdy jsem to nezkusil) a funkčním parametrem ref.

  4. Je to daleko od kovu. Potřebujete napsat primitiva, podprocesy jádra nebo něco? Hodně štěstí.

  5. I když mi nevadí nedostatek schopnosti zachytit sémantické chyby předem jako kompromis pro dynamiku, která Python nabídky, přál bych si, aby existoval způsob, jak zachytit syntaktické chyby a hloupé věci, jako je chybné názvy proměnných, aniž by bylo nutné kód skutečně spouštět.

  6. Dokumentace není tak dobrá jako jazyky jako PHP a Java), které mají silné firemní zázemí.

109
dsimcha

Nesnáším, že Python nedokáže rozlišit mezi deklarací a použitím proměnné. K tomu, aby k tomu došlo, nepotřebujete statické psaní. Bylo by hezké mít způsob, jak říci „toto je proměnná, kterou záměrně deklaruji, a já zamýšlí představit nové jméno, nejedná se o překlep “.

Kromě toho obvykle používám proměnné Python) ve stylu jednorázového zápisu, to znamená, že považuji proměnné za neměnné a nemění je po prvním přiřazení. Díky funkcím, jako je porozumění seznamu , je to vlastně neuvěřitelně snadné a usnadňuje sledování toku kódu.

Tuto skutečnost však nemohu zdokumentovat. Nic v Python mi nezabrání přepsání nebo opětovné použití proměnných.

V souhrnu bych chtěl mít dvě klíčová slova v jazyce: var a let. Pokud zapíšu do proměnné, která není deklarována žádnou z nich, Python by měl vyvolat chybu. let navíc deklaruje proměnné jako jen pro čtení, zatímco var proměnné jsou „normální“.

Zvažte tento příklad:

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

Všimněte si, že typy jsou stále implicitní (ale proměnné let jsou pro všechny záměry a účely staticky zadané, protože je nelze znovu vrátit k nové hodnotě, zatímco proměnné var mohou být stále dynamicky zadány).

Nakonec by všechny argumenty metody měly být automaticky let, tj. Měly by být pouze pro čtení. Obecně neexistuje žádný dobrý důvod pro změnu parametru, s výjimkou následujícího idiomu:

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

Toto by mohlo být nahrazeno poněkud odlišným idiomem:

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

Moje hlavní stížnost je navlékání, což není v mnoha případech (ve srovnání s Java, C a dalšími) tak výkonné kvůli globálnímu tlumočení zámku (viz „Uvnitř Python GIL“) (Odkaz ve formátu PDF) diskuse)

Existuje však multiprocesové rozhraní , které se velmi snadno používá, ale bude to těžší při využití paměti pro stejný počet procesů vs. vláken, nebo obtížné, pokud máte mnoho sdílených dat . Výhodou však je, že jakmile máte program, který pracuje s více procesy, může se škálovat napříč více počítači, což nemůže udělat program se závitem.

Opravdu nesouhlasím s kritikou dokumentace, myslím, že je vynikající a lepší než většina, pokud ne všechny hlavní jazyky.

Také můžete chytit mnoho běhových chyb běžících pylint .

44
cmcginty

Pravděpodobně, nedostatek statického psaní, které může zavést určité třídy runtime chyb, nestojí za přidanou flexibilitu, kterou poskytuje psaní kachen.

28
Jacob

Domnívám se, že objektově orientované části Python pocit jakéhosi "připevněného". Celá potřeba explicitně předat "já" každé metodě je příznakem, že je OOP komponenta nebyla výslovně plánována , dalo by se říci, ukazuje také Pythonova někdy válečná pravidla určování rozsahu, která byla kritizována v jiné odpovědi.

pravit:

Když říkám, že se Pythonovy objektově orientované části cítí „přišroubované“, myslím tím, že občas OOP strana se cítí poněkud nekonzistentně. Vezměte si Ruby, například: V Ruby, všechno je objekt a vy voláte metodu pomocí známé syntaxe obj.method (samozřejmě s výjimkou přetížených operátorů); v Pythonu je vše také objekt, ale některé metody voláte jako funkce, tj. přetížením __len__ vrátíte délku, ale namísto známějších (a konzistentnějších) zavoláte pomocí len(obj)obj.length Běžné v jiných jazycích. Vím, že za tímto návrhem jsou důvody, ale nemám je rád.

Navíc, Pythonův model OOP) postrádá jakýkoli druh ochrany dat, tj. Neexistují soukromí, chránění a veřejní členové, můžete je napodobovat pomocí _ A __ Před metodami, ale je to trochu ošklivé. Podobně Python nedostane docela dost aspekt předávání zpráv OOP vpravo).

27
mipadi

Věci, které se mi na Pythonu nelíbí:

  1. Threading (vím, že to již bylo zmíněno, ale stojí za zmínku v každém příspěvku).
  2. Žádná podpora pro víceřádkové anonymní funkce (lambda může obsahovat pouze jeden výraz).
  3. Nedostatek jednoduché, ale výkonné funkce/třídy čtení vstupů (jako cin nebo scanf v C++ a C nebo Scanner v Javě).
  4. Všechny řetězce nejsou ve výchozím nastavení unicode (ale pevné v Python 3)).
19
MAK

Výchozí argumenty s proměnnými datovými typy.

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

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

Obvykle je to výsledek drobných chyb. Myslím, že by bylo lepší, kdyby vytvořil nový objekt seznamu, kdykoli byl vyžadován výchozí argument (spíše než vytvoření jediného objektu, který se použije pro každé volání funkce).

Edit: Nejedná se o obrovský problém, ale když je třeba v dokumentech něco uvést, znamená to, že je to problém. To by nemělo být vyžadováno.

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

Zejména když to mělo být výchozí. Je to jen podivné chování, které neodpovídá tomu, co byste očekávali, a není užitečné pro velké množství okolností.

18
jsternberg

Některé z funkcí Pythonu, které jej činí tak flexibilním jako vývojový jazyk, jsou také považovány za hlavní nevýhody těch, které se používají pro statickou analýzu „celého programu“ prováděnou procesem kompilace a propojení v jazycích, jako jsou C++ a Java.

  • Implicitní deklarace lokálních proměnných

Lokální proměnné jsou deklarovány pomocí běžného příkazu přiřazení. To znamená, že proměnné vazby v jakémkoli jiném rozsahu vyžadují, aby kompilátor vyzvedl explicitní anotaci (globální a nelokální deklarace pro vnější rozsahy, zápis atributů přístupu například pro rozsahy). To masivně snižuje množství kotlové desky potřebné při programování, ale to znamená, že nástroje třetích stran pro statickou analýzu (například pyflakes) jsou potřebné k provádění kontrol, které zpracovává kompilátor v jazycích, které vyžadují explicitní deklarace proměnných.

  • Podporováno je „Monkey patchching“

Obsah modulů, objektů třídy a dokonce i zabudovaného oboru názvů lze za běhu upravit. To je nesmírně silné a umožňuje mnoho velmi užitečných technik. Tato flexibilita však znamená, že Python nenabízí některé funkce společné pro staticky zadané OO jazyky). Nejzajímavější je, že metoda „self“ parametr k instanci je explicitní spíše než implicitní (protože „metody“ nemusí být definovány uvnitř třídy, mohou být přidány později úpravou třídy, což znamená, že není příliš praktické předávat implicitně odkaz na instanci) a kontroly přístupu k atributům mohou být „ t snadno vynutitelné na základě toho, zda je kód „uvnitř“ nebo „mimo“ třídy (protože toto rozlišení existuje pouze během provádění definice třídy).

  • Daleko od kovu

Platí to také pro mnoho dalších jazyků na vysoké úrovni, ale Python má tendenci oddělit většinu podrobností o hardwaru. Systémové programovací jazyky jako C a C++ jsou stále mnohem vhodnější pro zpracování přímého přístupu k hardwaru (nicméně, Python s nimi docela šťastně bude mluvit buď prostřednictvím rozšiřujících modulů CPythonu, nebo, více přenosně, prostřednictvím knihovny ctypes).

14
ncoghlan
  1. Použití odsazení pro bloky kódu místo {}/začátek-konec, cokoli.
  2. Každý novější moderní jazyk má správné lexikální rozsah, ale ne Python (viz níže)).
  3. Chaotické dokumenty (porovnejte s dokumentací Perl5, která je vynikající).
  4. Strait-bunda (existuje jen jeden způsob, jak to udělat).

Příklad zlomeného rozsahu; přepis z tlumočnické relace:

>>> 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 a nonlocal byla zavedena klíčová slova pro oprava této hlouposti za design.

12
zvrba

Považuji pythonovu kombinaci objektově orientované this.method() a procedurální/funkční method(this) syntaxe za velmi znepokojující:

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

To je obzvláště špatné, protože velké množství funkcí (spíše než metod) je právě vypuštěno do globálního jmenného prostor : metody vztahující se k seznamům, řetězcům, číslům, konstruktérům, metaprogramování, všechny smíchané do jednoho velkého abecedně seřazený seznam.

Funkční jazyky jako F # mají přinejmenším všechny funkce správně pojmenované v modulech:

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

Takže nejsou všichni spolu. Navíc se jedná o standard, který se dodržuje v celé knihovně, takže je alespoň konzistentní.

Rozumím důvodům pro vykonávání funkce vs , ale i stále si myslím, že je špatný nápad je takto smíchat. Byl bych mnohem šťastnější, kdyby byla dodržena syntaxe metody, alespoň pro běžné operace:

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

Zda tyto metody mutují nebo ne, mít je jako metody na objektu má několik výhod:

  • Jedno místo pro vyhledání „běžných“ operací na datovém typu: jiné knihovny/atd. mohou mít další fantastické věci, které mohou udělat pro datové typy, ale „výchozí“ operace jsou všechny v metodách objektu.
  • Při volání Module.method(x) není třeba opakovat Module. Když vezmeme příklad funkčního seznamu výše, proč musím pořád říkat List znovu a znovu? Mělo by to vědět, že je to List a nechci na ni volat funkci Navigation.map()! Pomocí syntaxe x.map() to udržuje DRY a stále jednoznačné).

A samozřejmě má výhody oproti způsobu put-everything-in-global-namespace . Není to tak, že současný způsob je neschopný dělat věci. Je to dokonce dost těsné (len(lst)), protože nic není jmenné! Rozumím výhodám používání funkcí (výchozí chování atd.) Oproti metodám, ale stále se mi nelíbí.

Je to jen chaotický. A ve velkých projektech je nepořádek vaším nejhorším nepřítelem.

11
Haoyi

Nedostatek homoikonicity .

Python musel počkat, než 3.x přidá klíčové slovo „s“. V jakémkoli homoikonickém jazyce by to mohlo být triviálně přidáno do knihovny.

Většina dalších otázek, které jsem viděl v odpovědích, je jednoho ze 3 typů:

1) Věci, které lze opravit pomocí nástrojů (např. Vločky) 2) Podrobnosti o implementaci (GIL, výkon) 3) Věci, které lze opravit pomocí kódovacích standardů (tj. Funkce, které lidé tam nechtěli)

# 2 není problém s jazykem, IMO # 1 a # 3 nejsou vážné problémy.

8
Jason

Python je můj oblíbený jazyk, protože je velmi expresivní, ale stále vás chrání před příliš velkým počtem chyb. Pořád mám pár věcí, které mě obtěžují:

  • Žádné skutečné anonymní funkce. Lambda lze použít pro funkce s jedním příkazem a příkaz with lze použít pro mnoho věcí, kde byste v Ruby použili blok kódu. Ale v některých situacích to dělá věci trochu těžkopádnější, než by musely být. (Zdaleka neohrabaný, jako by to bylo v Javě, ale stále ...)

  • Nějaký zmatek ve vztahu mezi moduly a soubory. Spuštění "python foo.py" z příkazového řádku se liší od "import foo". Problémy mohou způsobovat i relativní importy v Python 2.x). Pythonovy moduly jsou však mnohem lepší než odpovídající funkce C, C++ a Ruby.

  • Explicitní self. I když rozumím některým důvodům, a přestože používám denně Python=, mám sklon zapomenout na to, že jsem na to zapomněl. Další problém s tím je, že se stává trochu únavným udělejte třídu z modulu. Explicitní já souvisí s omezeným rozsahem, na který si ostatní stěžovali. Nejmenší rozsah v Python je rozsah funkcí. Pokud vaše funkce zůstanou malé, jak vy by to neměl být problém sám o sobě a IMO často dává čistší kód.

  • Některé globální funkce, například len, které byste očekávali, že se jedná o metodu (ve skutečnosti je za scénami).

  • Významné odsazení. Ne samotný nápad, který si myslím, že je skvělý, ale protože je to jediná věc, která brání tolik lidem v vyzkoušení Pythonu, možná Python by bylo lepší s některými (volitelně) začátek/konec) Ignorování těchto lidí, mohl bych naprosto žít s vynucenou velikostí pro odsazení.

  • Že nejde o vestavěný jazyk webových prohlížečů, místo JavaScriptu.

Z těchto stížností je to úplně první, na kterém mi záleží, že si myslím, že by měl být přidán do jazyka. Ostatní jsou spíše menší, s výjimkou posledního, což by bylo skvělé, kdyby se to stalo!

7
Martin Vilcans

Python není zcela zralý: jazyk python 3.2 v tomto okamžiku má problémy s kompatibilitou s většinou aktuálně distribuovaných balíčků (obvykle jsou kompatibilní s python) Jedná se o velkou nevýhodu, která v současné době vyžaduje více úsilí o vývoj (najít potřebný balíček; ověřit kompatibilitu; zvážit výběr ne-tak dobrého balíčku, který může být kompatibilnější; vzít nejlepší verzi, aktualizovat ji na 3.2, která by mohla trvat dny, pak začněte dělat něco užitečného).

Pravděpodobně v polovině roku 2012 to bude menší nevýhoda.

Všimněte si, že jsem byl sestřelen fanouškem. Během diskuse s vývojáři však náš tým vývojářů na vysoké úrovni dospěl ke stejnému závěru.

Splatnost v jednom hlavním smyslu znamená, že tým může používat technologii a být velmi rychle v provozu a běží bez skrytých rizik (včetně problémů s kompatibilitou). Třetí strana python balíčky a mnoho aplikací ne) pro většinu balíčků dnes pracujte v rámci 3.2. To vytváří více práce v oblasti integrace, testování, reimplementace samotné technologie místo řešení problému po ruce == méně vyspělá technologie.

Aktualizace pro červen 2013: Python 3 má stále problémy s vyspělostí. Každý člen týmu tak často zmiňuje potřebný balíček a poté řekne „kromě toho, že je pouze pro 2,6“ (v některých z těchto případů Implementovali jsme řešení pomocí soketu localhost pro použití balíčku 2.6-only s 2.6 a zbytek našich nástrojů zůstal s 3.2). Ani MoinMoin, čistě pythonová wiki, není zapsána v Python = 3.

5

Pythonův rozsah je špatně narušen, což činí objektově orientované programování v Python velmi nepříjemné).

4
Mason Wheeler

Modifikátory přístupu v Python nejsou vynutitelné - je obtížné psát dobře strukturovaný, modularizovaný kód.

Předpokládám, že je to součást zlomeného rozsahu @ Masona - což je obecně velký problém s tímto jazykem. U kódu, který má být čitelný, se zdá docela obtížné zjistit, co může a mělo by být v rozsahu a jaká bude hodnota v kterémkoli daném okamžiku - v současné době přemýšlím o přechodu od Python jazyk kvůli těmto nevýhodám.

To, že „všichni souhlasíme s dospělými“, neznamená, že neděláme chyby a nefungujeme lépe v silné struktuře, zejména při práci na složitých projektech - odsazení a bezvýznamné podtržítka se nezdají být dostatečné .

4
Vector

Moje gripy o Pythonu:

  • Bolted-on OOP (Viz odpověď @ mipadi pro podrobnější informace o této otázce)
  • Nefunkční implementace lambd
  • Rozsah otázek
  • Žádné trvalé sbírky ve standardní knihovně
  • Špatná dostupnost vestavěných DSL
4
missingfaktor

Vícenásobné odesílání není dobře integrováno do zavedeného systému typu s jedním odesláním a není příliš výkonné.

Dynamické načítání je masivním problémem v paralelních souborových systémech, kde sémantika podobná POSIX vede ke katastrofickým zpomalením pro operace náročné na metadata. Mám kolegy, kteří spálili čtvrt milionu jaderných hodin právě získávání Python (s numpy, mpi4py, Petsc4py a dalšími rozšiřujícími moduly)) načtených na jádra 65k. (Simulace přinesla významnou novou vědu výsledky, takže to stálo za to, ale je to problém, když se spálí více než barel ropy, aby se načítalo Python jednou.) Neschopnost statického propojení nás přinutila jít k velkým zkroucení získejte přiměřené doby načítání v měřítku, včetně oprav libc-rtld, aby dlopen provedl kolektivní přístup do systému souborů.

3
Jed
  • docela hodně velmi běžných knihoven a softwaru třetích stran, které jsou široce používány, nejsou Pythonic. Několik příkladů: soaplib, otvírák, reportlab. Kritika je mimo rozsah, je tam, je široce používaná, ale způsobuje matoucí kulturu python) (bolí to motto, které říká: „Měla by být jedna - a nejlépe jen jedna - - zřejmý způsob, jak toho dosáhnout “). Známé Pythonicovy úspěchy (jako Django nebo trac) se zdají být výjimkou.
  • potenciálně neomezená hloubka abstrakce instance, třídy, metaclass je koncepčně krásná a jedinečná. Abychom to zvládli, musíte hluboce znát tlumočníka (v jakém pořadí python kód, atd.). Není obecně znám a používán (nebo používán správně), zatímco podobná černá magie jako jako generiky C # se zdá, že je koncepčně více spletitý (IMHO) poměrně rozšířeně známý a používaný, úměrně.
  • abyste získali dobrý přehled o modelu paměti a závitování, musíte být s pythonem docela zkušení, protože neexistují žádné komplexní specifikace. Prostě víte, co funguje, možná proto, že jste si přečetli zdroje tlumočníka nebo zkušené vtípky a zjistili, jak je opravit. Například existují pouze silné nebo slabé odkazy, nikoli měkké a fantomové odkazy Java. Java má vlákno pro sběr odpadků, zatímco neexistuje žádná formální odpověď o tom, kdy k odběru odpadků dojde v python; stačí jen pozorovat, že se sběr odpadků nestane) pokud není spuštěn žádný kód python, a došel k závěru, že se to pravděpodobně někdy stane, když se pokoušíme přidělit paměť. Může to být složité, když nevíte, proč nebyl uvolněn zamčený zdroj (moje zkušenost s tím byl mod_python ve freeswitch).

Každopádně python je můj hlavní jazyk již 4 roky. Být fanoušky, elitáři nebo monomaniaky není součástí kultury python).

3
vincent

I laskavost python a první nevýhodou, která mi napadne, je, když při komentování příkazu jako if myTest(): musíte změnit odsazení celého provedeného bloku, který byste nechtěli Nemusím dělat C ani Java. Ve skutečnosti v python místo toho, abych komentoval klauzuli if-place, začal jsem to komentovat takto: `if True: #myTest ( ), takže nebudu muset měnit ani následující blok kódu. Protože Java a C se nespoléhají na odsazení, usnadňuje to komentování příkazů s C a Java).

3
Niklas
  1. Výkon není dobrý, ale zlepšuje se s pypy,
  2. GIL zabraňuje použití vláken pro zrychlení kódu (i když je to obvykle předčasná optimalizace),
  3. Je to užitečné pouze pro programování aplikací,

Má však některé skvělé funkce pro uplatnění:

  1. Je to ideální pro RAD,
  2. Je snadné propojit s C (a pro C vložit python interpret),
  3. Je to velmi čitelné,
  4. Je snadné se naučit,
  5. Je to dobře zdokumentováno,
  6. Baterie jsou skutečně zahrnuty, standardní knihovna je obrovská a pypi obsahuje moduly pro prakticky všechno,
  7. Má zdravou komunitu.
3
dan_waterworth
  • Podivné OOP:
    • len(s)__len__(self) a další "speciální metody"
    • extra speciální metody, které by mohly být odvozeny z jiných speciálních metod (__add__ a __iadd__ pro + a +=)
    • self jako první parametr metody
    • můžete zapomenout zavolat konstruktoru základní třídy
    • žádné modifikátory přístupu (soukromé, chráněné ...)
  • žádné konstantní definice
  • žádná neměnitelnost pro vlastní typy
  • GIL
  • špatný výkon, který vede ke kombinaci Python a C a problémy s sestavením (hledání C lib, závislost na platformě ...)
  • špatná dokumentace, zejména u knihoven třetích stran
  • nekompatibilita mezi Python 2.xa 3.x
  • špatné nástroje pro analýzu kódu (ve srovnání s tím, co je nabízeno pro staticky zadané jazyky, jako je Java nebo C #)
2
deamon

„Neměnitelnost“ není přesně to silné. AFAIK čísla, n-tice a řetězce jsou neměnné, všechno ostatní (tj. Objekty) je zaměnitelné. Porovnejte to s funkčními jazyky, jako je Erlang nebo Haskell, kde je všechno neměnné (alespoň ve výchozím nastavení).

Immutabilita však opravdu svítí souběžně *, což také není Pythonova silná stránka, takže je to alespoň následek.

(* = Pro nitpickery: Mám na mysli souběžnost, která je alespoň částečně rovnoběžná. Myslím, že Python je v pořádku s "jednovláknovou" souběžností, ve které neměnitelnost není tak důležitá. (Ano, Milovníci FP, vím, že neměnitelnost je skvělá i bez souběžnosti.))

0
Kosta

Rád bych měl explicitně paralelní konstrukty. Častěji než ne, když píšu seznam s porozuměním jako

[ f(x) for x in lots_of_sx ]

Nezajímá mě pořadí, ve kterém budou prvky zpracovány. Někdy mi vůbec nezáleží na tom, v jakém pořadí jsou vráceny.

I když to CPython neumí dobře, když moje f je čistý Python, takové chování by bylo možné definovat pro další implementace.

0
rbanffy

Python nemá žádnou optimalizaci pro chvilkové hovory, většinou z filozofické důvody . To znamená, že opakování ocasu na velkých strukturách může stát paměť O(n) (kvůli zbytečnému zásobníku, který je zachován) a bude vyžadovat, abyste přepsali rekurzi jako smyčku, abyste získali O(1) paměť.

0
a3nm