Přes deset let jsem se živil programováním v PHP. Poslední rok jsem ale přesedlal na Python. Jaké má Python oproti PHP výhody a jaké slabiny?
Hlavní výhodu Pythonu oproti PHP (a dalším Cčkovým jazykům) vidím v jeho velmi čisté a obrovsky expresivní syntaxi.
Na ukázku přikládám obrázky s pár srovnáními: práce s poli, čtení souboru s pomocí context manageru, předávání parametrů (keyword parametry, různý počet parametrů), property a deskriptory.
Python umožňuje i další věci, pro které se ale v PHP těžko hledá alternativa. Např. meta třídy nebo dekorátory:
import time
def timeit(f):
def wrapper(*args, **kwargs):
start = time.time()
res = f(*args, **kwargs)
end = time.time()
print('Elapsed time for {} is {}s'.format(
f,
end - start
))
return res
return wrapper
@timeit # dekorátor
def hello():
time.sleep(1)
print('Hello!')
hello()
Dekorátory jsou vlastně jen syntaktický cukr pro zápis "hello = timeit(hello)", jsou ale velmi užitečné. V uvedeném příkladu pomocí přidání dekorátoru timeit na funkci hello mohu změřit jak dlouho trvá vykonávání funkce hello. Dekorátory se používají na cachování, kontrolu práv, registraci callbacků apod.
Pro hodně lidí je těžko zkousnutelné, že v Pythonu odsazování kódu nese význam. Zpočátku jsem měl také obavy, jestli chybějící složené závorky nezhorší čitelnost kódu, ale ukázaly se jako plané. Složené závorky jsou vlastně nadbytečná informace, protože každý příčetný programátor tak jako tak kód podle zanoření kód i odsazuje.
Standardní knihovna Pythonu má oproti PHP jednu velkou výhodu - je rozdělená do cca 200 modulů. To přispívá k daleko lepší orientace v knihovně.
Interpretr pythonu také načítá do paměti jen ty knihovny, které opravdu chceme, a pravděpodobně i díky tomu má menší paměťový otisk (8,5MB) než PHP (22,5M).
Vzhledem ke své víceúčelovosti má Pythonní knihovna také o něco širší záběr a najdeme tu tak i třeba moduly pro komunikaci s cizími C knihovnami, na tvorbu konzolových aplikací (curses), práci s multimédii, nebo na asynchronní IO, o kterém jsem psal minule.
Jako velkou výhodou Pythonu oproti PHP vnímám jeho interaktivní konzoli.
Není potřeba psát echo pro vypsání výsledku, případný výsledek příkazu se vypíše automaticky:
>>> 1 + 2 + 3 6
Pokud se do konzole vypíše nějaká datová struktura složená ze základních typů, je výpis validním python kódem. Můžeme ho tedy zkopírovat a hned použít:
>>> {x: x**2 for x in range(1, 5)}
{1: 1, 2: 4, 3: 9, 4: 16}
Kromě konzole dodávané přímo v distribuci pythonu exisují i další konzole, které nabízejí různé pokročilé funkce, např. obarvování kódu, napovídání (viz obrázky), benchmarking, prezentační mód apod.
PHP vzniklo jako skriptovací jazyk na oživení webových stránek. Od té doby ušlo velmi dlouhou cestu, ale mimo svět webu se nikdy moc nerozšířilo.
Oproti tomu Python byl od počátku navrhován jako obecný skriptovací jazyk a dnes se kromě webu prosazuje i v oblastech zpracování velkých dat, strojového učení nebo při vývoji operačních systémů.
Ve světe PHP jsem se v ČR vlastně nikdy nesetkal s nějakou komunitou kolem jazyka, existuje pouze komunita okolo Nette.
Python mají vývojáři asi celkově víc rádi a tak u nás existují pravidelné PyVo srazy a za měsíc bude v Brně dokonce celá konference věnována Pythonu - PyCon CZ.
Měl jsem to štěstí se v létě zúčastnit konference EuroPython ve španělském Bilbau a celkový pocit z přednášek, lidí a směřování celé platformy byl velmi pozitivní, což se například po přednášce zakladatele PHP Rasmuse Lerdorfa na WebExpu rozhodně říct nedalo :)
Abych pouze nechválil, existuje i pár věcí, kde si myslím, že Python za PHP pokulhává.
Prvním nedostatkem je způsob práce se jmennými prostory. V PHP se používá klíčové slovo namespace, pomocí kterého si můžete projekt libovolně rozdělit do jmených prostorů.
V Pythonu rozdělení do jmenných prostorů odpovídá souborům a složkám, což je sice pohodlné, ale může být občas omezující a svádět k vytváření příliš dlouhých souborů.
Dalším velkým nedostatkem byla chybějící volitelná typovost parametrů (v PHP type hinty), která byla přidána až do verze 3.5. V PHP díky type hintům existují pokročilé Dependency injection kontejnery, které fungují poloautomaticky. Ve světě Pythonu se obecně technika Dependency injection příliš nepoužívá, což je možná škoda.
PHP je dobrý jazyk, který má ale z mého pohledu už zastaralou Céčkovou syntaxi a chaotickou standardní knihovnu.
Python je velmi příjemný a intuitivní jazyk na čtení i psaní, který přestože je o 4 roky starší než PHP, tak působí mnohem moderněji.
Zpětně jsem tak za své rozhodnutí začít pracovat v Pythonu velmi rád.
Nejprve čtu:
"Standardní knihovna Pythonu má oproti PHP jednu velkou výhodu - je rozdělená do cca 200 modulů. To přispívá k daleko lepší orientace v knihovně."
Pak čtu:
"PHP je dobrý jazyk, který má ale z mého pohledu už zastaralou Céčkovou syntaxi a chaotickou standardní knihovnu."
Tak jaká je ta standardní knihovna dobrá nebo na kni-hovno?
-FE
#4 martin: To by asi bylo na samostatný článek :) Každopádně jsou a je jich dost - Django (Symfony?), Flask (Nette?), SQLAlchemy (Doctrine), atd.
- Nejvetsi fail Pythonu je, ze ani po 7 letech se jeste komunita nepresunula na 3.x radu.
- Jinak dekorator je sice pekna vec, ale ze by to mel byt nejaky killer feature. Je to takove programovani pres anotace. Na hello = timeit(hello) nic spatneho/nepohodlneho nevidim.
- pro PHP existuje (myslim ze vic) REPL, ze nejsou "officialni" je pravda, ale na 1*2 to staci. Nic jineho se v tom stejne moc delat neda, to uz mi spis dava takova konzole smysl v Haskellu, kde se hodi si veci otypovat.
- napsat na "Ve světě Pythonu se obecně technika Dependency injection příliš nepoužívá" reakci, ze je to možná! škoda je teda opravdu ... rekneme ovlivneny uhel pohledu. Je to proste spatne.
- viceucelovost Pythonu je urcite supr, to jej u PHP skoda. Zejmena kvuli omezene knivhovne pro matematiku, etc. Ale s PHP7+ budou asi vetsi zmeny.
V pythonu existuje přímo buitin modul timeit, který umí měřit podstatně přesněji, než tohle.
Jinak dekorátory začnou dávat smysl ve chvíli, kdy mají parametry, nebo je jich víc.
#6 Jan Škrášek: Jan Škrášek:
V první řadě Python je objektový jazyk s přehlednou objektovou standardní knihovnou, které je z velké části v Pythonu samotném. To je naprosto zásadní rozdíl od PHP, které je v podstatě slepec různých Cčkových extensions napsaných tak, jak se to autorovi zrovna líbilo.
Víceúčelovost je druhá věc, Python byl od začátku cílem na to, aby se v něm dobře psaly všechny druhy aplikací, takže mohl plnohodnotně nahradit do té doby používaný Perl - takže GUI aplikace, konzolové aplikace, ale i různé démony a služby, samozřejmě i web aplikace.
V PHP tak možná kromě webu ještě ty konzolové skripty a tím to hasne.
A za třetí, Python se velmi jednoduše dát zaintegrovat do jiných aplikací a tak umožnit jednoduše uživatelky skriptovat danou aplikaci a mimo jiné i tak krásně využít ten REPL.
To jsou také podle mě důvody, proč si Python vybírají větší firmy, které v něm pokryjí kompletně své potřeby, např. právě Seznam a samozřejmě Google, Redhat, Suse atd.
Tohle PHP bohužel nikdy nedožene a nezmění to ani PHP 7, type hinty namespaces atd.
#6 Jan Škrášek: Přechod na Python 3 je problém, ale nepřijde mi nijak zásadní. Vnímám to jako mnohem lepší situaci, než kdyby se rozhodli žádné zpětně nekompatibilní změny nedělat a byl tu jen Python 2.
Také jsem byl z absence dependency injection hodně překvapený. V PHP jsem to považoval za velmi velmi cenou techniku. Abych se přiznal, tak se mi za ten rok ale nikdy nestalo, že bych si mohl říct: "Nojo, tenhle problém nastal, protože nemáme DI!". Python zkrátka s kódem a jeho závislostmi pracuje trochu jinak a osobně si nejsem úplně jistý, jak moc je to špatně nebo ne. Jestli se nepoužitím DI opravdu zvyšuje provázanou kódu a snižuje znovupoužitelnost apod.
#5 Daniel Milde: chápu že jsou
zajímají mě praktické zkušenosti. a srovnání. je nette opravdu tak skvělé, nebo jsou čeští phpkari zaslepení ?
#10 martin: Srovnání by opravdu bylo na samostatný článek. Nette je velmi dobrý framework, který má některé své velmi pěkné vlastnosti (laděnka, šablony, DI).
Třeba Flask je také velmi dobrý framework, který má zase trochu jiné pěkné vlastnosti (např. live debug -https://twitter.com/danielmilde/status/608999391718993922)
Já jsem z Pythonu odešel, a to přesto, že se mi ten jazyk velice líbí. Hlavní důvod je jednoduchý: Programovací jazyk, kterému je možné jen tak mir nichts dir nichts po zabydlení se a 17 letech existence změnit zpětně nekompatibilně syntaxi bez vážného důvodu a bez opravdu výrazných benefitů - je jazyk, který nechci používat. (Přechod z Python 2 -> 3) Jazyk si zkrátka neváží investice progrmaátorů, a proto jsem udělal papá, jakmile jsem se dozvěděl, že Rossum o tom uvažuje a komunita není proti.
Python je mimo jiné jeden z nejpomalejších jazyků vůbec. Rossum se soustředil na překopávání syntaxe, nikoli na kvalitu interpretru, ono dá vcelku rozum, že když se něco překopává, tak se na optimalizaci jeden vykašle.
PHP udělalo největší chybu, že jakožto dynamicky typovaný programovací jazyk opsalo objekty ze staticky typované Javy, a tak vznikl neuvěřitelně zprasený myšmaš. Python tuto zásadní chybu neudělal, a objekty jsou pro něho postě "duck typing". PHP je vnitřně uvnitř jazyk téměř filozoficky identický s Pythonem, ale nenechal se zprasit Javou.
Kromě toho PHP ani ve verzi 7 nedokázalo propašovat do jazyk datový typ řetězec, string je pouze bajtový blob. Funkce strlen() v PHP se tváří, a i manuál to tak píše, že určuje délku řetězce, ale třeba UTF-8 řetězec to neobslouží správně. V Pythonu je oddělení bajtů a znaků zcela správně a dobře. Myslím, že ve 21. století by programovací jazyk mohl disponovat datovým typem řetězec.
PHP dále nemá překlad do byte kódu, protože jeho autoři ho chtějí nabízet extra a komerčně. Stejně tak podpora debugování je v PHP poněkud poněkud přes ruku - opět stejný důvod. Těmito ptákovinami Python pokud je mi známo také netrpí. Takže v PHP se při každém spuštění znovu zparsují zdrojáky, znovu přeloží do byte kódu, ten se vykoná, a vše se zapoment. Důvod: kapitalismus. Opět takovéto ptákoviny v Pythonu nejsou, Python si byte kód uloží, a pokud se zdroják nezměnil, po druhém spuštění jej použije. Zde bych také hledal další mohutnou paměťovou stopu v neprospěch PHP, ale také zátěž CPU v neprospěch PHP a špatnou škálovatelnost PHP.
Miloslav Ponkrác
#12 Miloslav Ponkrác: S tou rychlostí Pythonu jste tedy vedle jak ta jedle, PyPy to s JITem švihá tak, že hravě strčí do kapsy i jazyky kompilované přímo do binárky (např. Go), viz. minulý článek tady na blogu o async io.
#13 koubel: Testy jsem neviděl, ale v minulosti jsem viděl například testy dokazující, že Java je rychlejší, než C, nebo dokonce rychlejší než nativní strojový kód.
Kdysi jsem měl tendenci ty testy a sledovat a rozebírat, dnes už vím, že dokazují hlavně neschopnost programátorů napsat dobře program v těch jazycích kompilovaných do binárky a více vypovídají o testujících než o rychlosti jazyků. Jestli je to případ i vámi zmíněného testu nevím. Ale po cca 40. testu, kde pokaždé byly jen špatně napsané programy testujícími tak nějak už nemám zájem žádné další testy sledovat.
Udělat dobrý test je těžké, a vyskytne se možná tak jednou mezi tisícovkou špatných testů.
Můj názor je stále stejný, pokud je jakýmkoli způsobem Python rychlejší než strojově orientované jazyky (C, C++, apod.), pak je takový test špatně udělán. O ničem jiném to nesvědčí.
#12 Miloslav Ponkrác: každá rozumná aplikace v php používá opcache
http://php.net/manual/en/intro.opcache.php
#12 Miloslav Ponkrác: Osobně si myslím, že ty nekompatibilní změny za to opravdu stáli. Python 3 je velmi pěkný jazyk, který se zbavil spousty historického balastu a problémů.
PyPy je velmi rychlé, protože ono ve skutečnosti zjistí, co program dělá, převede to do nativního kódu, zoptimalizuje a pak už frčí jak blesk.
Není tedy zase tak moc divné, že PyPy dokáže porazit Go, Node.JS apod.
Python (CPython) sám o sobě zatím není příliš optimalizován pro rychlost a ani se s tím příliš nepočítá, protože: existuje PyPy, Nutika apod.; existuje cython; dají se bottlenecky přepsat do C.
#16 Daniel Milde: Já si zase myslím, že ty nekompatibilní změny v Pythonu 3 za to nestály. A zahlasoval jsem svou osobou a diskvalifikoval jsem ho. Ačkoli jsem python používal jako hlavní jazyk, byl jsem aktivní i v komunitách ve světě, tak jakmile jsem se dozvěděl, co se chystá, tak jsem ze dne den Python stopl. Protože jsem byl aktivní, dozvěděl jsem se to asi rok, možná dva před změnou, a od té doby jsem nenapsal jediný řádek v Pythonu. A v současné době už jsem vše pythonovské nahradil, takže se s Pythonem vůbec nesetkávám.
Na změny v Pythonu 3 jsem se podíval a studoval jsem je, protože mě to zajímalo. Jen jsem se utrvdil, že se jednalo spíše o vrtoch Rossuma, než o něco, co by za to stálo.
Každá změna, i destruktivní, dokáže pročistit jazyk, protože prostě některé 10 let staré artefakty zrušíte. Ale většina lidí hlasovala jako já. Python měl v té době před Pythonem 3 velmi našlápnuto na mnohem větší popularitu a používanost, než je dnešní. Ve své podstatě se Python ze zbytečné změny, kdy si IMHO Rosssum chtěl pouze sám pro sebe dokázat "já můžu, mám tu moc to udělat" ještě nevzpamatoval, jinak bych o něco výše nečetl vzdechy, že stále někdo používá Python 2.
Jednoduše to bylo tak, že Rossum se kamarádil s autorem Perlu, který nekompatibilně překopal Perl 6 a Rossum se rozhodl že totéž udělá s Pythonem. Odměna je zcela zasloužená. Perl, tehdy velmi populární jazyk je dnes na okraji zájmu, Python je mnohem níže, než mohl být. Pro mě jsou oba jazyky odepsány, jazyk, který poruší drasticky zpětnou kompatibilitu, a nedá za to sakra výhodné benefity, které musejí senzačně stát za to, je jazyk neseriózní a v praxi nepoužitelný. Toho se řídím, a řídit budu - a nejspíše se tím bude řídit i mnoho praktiků.
Máte-li totiž stovky tisíc rádků odladěného, otestovaného a roky v praxi prověřeného kódu, který je tím pádem spolehlivý, tak nekompatibilní změnou syntaxe jazyka začínáte od píky. Máte v tom člověkoroky práce, spousty peněz a času - tedy obrovskou investici. A na já se takovému jazyku, který tuto investici hodlá BEZ SAKRA PÁDNÉHO DŮVODU poslat do kopru můžu z vysoka vykašlat.
Zkuste říci linuxové komunitě, že odteď se nekompatibilně změní unixový shell. Že to pročistíme a bude to paráda. Cože, vy na tom máte stroje a podnikání, které vám udělá miliardové škody při chybách v shellu? Ach vy nemoderní konzervy, copak nechápete, jak shell bude lepší a pročištěný? Nebo můžeme změnit nekompatibilně Céčko, on si Rossum to CPython klidně napíše a odladí znovu pro kratochvíli autorů Céčka, co vy na to? Proč by Rossum nedělal jen tak pro naší radost zbytečnou práci?
Ne nadarmo Python není jazykem seriózním, ale pouze skriptovacím. Tedy na jednorázové zpracování dat nebo na krátkodobý projekt. Nešťastníci, co udělali v Pythonu dlouhodobé projekty a nepočítali se špatnými osobnostními stránkami autora Pythonu Rossuma, teď pytlíkují na Pythonu 2, nebo zbytečně dávali čas a peníze do přechodu na Python 3. Já to dělám jednodušeji - já jazyk nectící zpětnou kompatibilitu vyhazuji ze svého portfolia někam do černé díry a končím s ním. Když X jazyků dokáže držet syntaxy i mnoho desetiletí, tak jakýkoli důvod pro porušení je většinou jen neserióznost jazyka.
Proto můžeme porovnávat Python zezhora a zdola, zleva i z prava, ze všech stran. Jazyk je to pěkný, ale nikdy nikomu nedoporučím v něm dělat něco vážného. Pythonu chybí to hlavní, nedává záruky ochrany investic programátorů a vývojářů a ochranu jejich práce. Může být třeba platinový a pozlacený, ale takový jazyk já nechci a nikomu nikdy nedoporučím na vážný projekt.
#17 Miloslav Ponkrác: Ano, nekompatibilní změny jsou nepříjemné, ale jako takovou tragédii bych to zase neviděl. Python 2 bude podporovaný do roku 2020, tzn. 12 let po vydání verze 3. To mi přijde jako dostatek času na přechod.
Na Pythonu jede celý Seznam, jen náš projekt je cca 400t řádek Python kódu, takže ani s tou seriózností bych to tak špatně neviděl :)
#16 Daniel Milde: Python je typický glue language, tedy obrovskými kusy C kódu ve formě knihoven spojenými trochou pythonovského kódu.
Pokud tedy měřím rychlost jazyka, tak měřím rychlost konstrukcí vlastního jazyka, ideálně s vyloučením toho volání Céčka pod tím. To je rychlost jazyka. Například rychlost výpočtu řešení soustavy rovnic o mnoha proměnných bez volání nějakých knihoven pro maticové výpočty, pouze kódem v Pythonu. Tam se ukáže rychlost jazyka. Totéž se pak napíše třeba v C, C++, Go a dalším. To je jediná možnost, jak seriózně otestovat rychlost jazyka. Dále se dané programy přeloží/interpretují v různých podmínkách na různých strojích.
Rychlost volání asynchronní komunikace, kde velká část závisí na kódu nepsaném z Pythonu a různé knihovny dělají jen tenkou obálku o jazyce nic nezjistí. Daleko větší vliv je, jak moc se trefíte danými voláními do noty operačnímu systému a jeho službách a jiné vlivy.
Tedy tvrzení, že "Python porazí Go" bude pravda, až se nebude jednat převážně o volání knihoven, ale o vlastní kódy.
Google projekty mě nezajímají, mají obvykle jepičí životy, a Google je poměrně často ukončuje. Tedy mě ani příliš nezajímá jazyk Go. Python určitě jazyk Go délkou existence v budoucnu přežije. Pokud by mě zajímalo programovat na jazycích bez kostry a základu, ať už proto, že Python nezaručuje zpětnou kompatibilitu, tedy nemá základní kámen, nebo Go, který nezaručuje, jestli se na něho Google zítra nevykvajzne, pak bych to asi porovnával.
V první řadě mě zajímá rychlost vůči dobře napsanému C/C++ programu jako etalon. JIT není samospasitelný. Protože i to zjištění co program dělá, a kompilace se jaksi provádí za běhu programu a k času provedení programu se přičítá. Může tedy program i zpomalit.
#18 Daniel Milde: Kdybych chtěl být zlý, tak bych jen řekl, že seznam podle toho vypadá. Mám pocit, že jde o upadající firmu, byť setrvačností se bude jako kolos držet dlouho.
Nehci to tu zaneřádit, tato diskuse má být přehledná. Napíši jen, že je mnoho jazyků, které zpětnou kompatibilitu, a tedy investice do něj, ctí. Tudíž není důvod podporovat jiné jazyky na dlouhodobé projekty.
Podpora jazyka do roku 2020 je hezká, ale tato podpora není zaručena u knihoven a autorů knihoven třetích stran, a řekl bych, že u řady z nich už podpora Pythonu 2 skončila, u některých již před léty. Takže de facto plná podpora Pythonu 2 už není ani dnes.
Dále už se ke zpětné kompatibilitě vyjadřovat nebudu, řekl jsem vše, a tato diskuse je pro komplexní pohled. Jenom by mělo být zmíněno, že toto je vážný nedostatek Pythonu - a že se to klidně může stát znovu. V roce 2018 může Rossum přivést na zpět Python 4 se zcela nekompatibilní syntaxí s Pythonem 3 a zaručit setrvání Pythonu 3 do roku 2025. To se klidně může stát, pokud není zpětná kompatibilita daná na přední místo, tak jak je to třeba u C, C++, Fortranu, a mnoha dalších jazyků, třeba horších, ale tím pádem seriózních.
Howgh.
Nemůže sémantické odsazování způsobovat problémy při merge konfliktech? Už několikrát se mi v jiných programovacích jazycích stalo, že nějaký kus kódu byl špatně odsazen a když jsem pátral po příčině, tak to byla právě nepozornost při merge konfliktu. V PHP a jiných jazycích jde jen o nepatrný problém, protože kód funguje pořád stejně, navíc to může chytit nějaký style checker. V Pythonu by šlo o katastrofu, protože kód, který se měl třeba vykonat podmíněně, se vykoná nepodmíněně (goto fail).
#8 koubel: Google Pythonem rozhodně nepokrývá všechny své potřeby a není to tedy důvod, proč ho používá. Kromě Pythonu se v Google srovnatelně nebo víc používá také C++, Java, JavaScript a Go.
#12 Miloslav Ponkrác: Extenze Opcache je přímo součástí PHP od verze 5.5, tedy přes dva roky.
#21 Jakub Vrána: A nezdá se vám, že jazyk by měl optimalizovat automaticky a jako celek? Styl, kdy v PHP verze 458 konečně dostaneme prostředky a extenze abychom z toho mohli doprogramovat jazyk se všemi featurami, které dostane každý jiný programovací jazyk automaticky s verzí 1.0? Kromě toho je to extension, to znamená, že není zaručeno, že to na hostingu bude k dispozici. A také bych rád aby jazyk optimalizoval a dělal tyhle věci na pozadí, jak to dělá snad každý jazyk, nikoli, abych si PHP programoval program make a building.
#21 Jakub Vrána: Zatím jsem na problém s odsazením při mergi nenarazil. Ale je možné, že by se dal vymyslet nějaký specifický scénář, při kterém by nějaký problém opravdu nastal. Ostatně už tak jednou nebo dvakrát jsem byl svědkem toho, že Git udělal merge "nějak divně" a byly v něm chyby.
#22 Miloslav Ponkrác: Opcache je přímo součástí PHP. Sice až od verze 5.5, ale je tam a nemyslím si, že by na nějakém rozumném hostingu byla vypínána.
Chápu, že Python 3 může být pro hodně lidí velký problém, já to vnímám spíš jako výzvu.
#23 Daniel Milde: Cokoli, co se dá vypnout nezávisle na programátorovi, je z definice "nepovinné rozšíření jazyka". Programátor nemůže spoléhat na "myslím si".
Výzva je cokoli - třeba skočit z Nuseláku nebo přijmout a ubytovat v Praze 20 miliónů imigrantů, nebo zítra vyhlásit válku Číně a zaútočit na ní vekšrou vojenskou výzbrojí, co Česká republika má.
Já bych na místě Rossuma, kdybych měl nutkání jazyk takto změnit, tak bych do Pythonu přidal mnohem více, aby to stálo za to. A zároveň přeprogramoval automatický a 100% účinný konvertor, který by s maximální zárukou bezchybnosti převodu konvertoval jak Python 2, tak C knihovny pro Python 2 do Pythonu 3. Bez tohoto bych se do toho vůbec nepouštěl. Tohle je výzva! To co udělal Rossum je zpackání ála tunel Blanka.
A tím už definitivně končím, ať dám v diskusi i prostor jiným.
#22 Miloslav Ponkrác: Souhlasím, že by to mohlo být defaultně zapnuté. Na druhou stranu mi to je i tak příjemnější než Python, který zasírá adresáře
*.pycsoubory.
#25 Jakub Vrána: Abych řekl pravdu, mně je filozofie PHP ve stylu naprogramuj si v PHP samo doma vlastní programovací jazyk je docela cizí. V PHP dělám bohužel dost, už proto že je to de facto jediný hostingy široce podporovaný jazyk, a od počátku mám dojem, že PHP není programovací jazyk, že je to nedostavěný kit, ze kterého si můžete po pár člověkoměsících udělat a vytvořit nad ním jakž takž použitelný programovací jazyk. Můžete se separé postarat o věci, které jsou v jiným jazycích jaksi rovnou. Kdyby PHP samo od sebe optimalizovalo alespoň tak málo jako Python, odpustil bych mu i zasírání adresářů nějakými .phpc soubory.
Jinak spuštění python -B žádné .pyc a .pyo soubory nevytváří. Stejně tak jako přítomnost proměnné prostředí PYTHONDONTWRITEBYTECODE.
Kromě toho Python může ukládat byte kód do podaresáře __pycache__.
#26 Miloslav Ponkrác: Jsem docela zvědavý jak se s rozbitím kompatibility popere PHP svět. Myslím, že PHP 7 za nějaké ty změny taky stojí.
Píše Daniel Milde aka Dundee
Powered by NORS 4.3.9©2007-2015 Daniel Milde aka Dundee |
|
|
We use cookies. You agree by using this website.
Jak se v pythonu bezne resi predavani zavislosti?