> Když komunita přijme rozhodnutí, tak by o něm měla přestat diskutovat.
Komunita neprijima v Pythonu rozhodnuti, to dela prave BDFL na zaklade predchozi diskuze. A problem v tomto konkrektnim pripade byl, ze to akceptoval pomerne zvlastnim zpusobem, viz:
Ve zkratce lide meli pocit, ze je spis Dictator nez Benevolent Dictator For Life.
Uvidíme jak to ovlivní vývoj. Bylo by docela zajímavé porovnat, jak se vyvýjí jazyky podle toho, jestli byly navrženy skupinou, jedincem atd. atp. Někde jsem četl, že historicky jsou úspěšnější jazyky, které navrh jedinec a ne skupina. Další vývoj ale už tam nebyl zahrnut -- třeba C++ taky nevrhl jedinec a dnes je na to celá komise. Smalltalk se taky v inkarnaci Pharo proměňuje a Python se změnil hodně i když to tak nemusí vypadat.
Protoze clovek pripadne miniskupina ma lepsi sanci udrzet konzistenci nez velka skupina. Je to krasny priklad toho ze pridani vice lidi na projekt ma pri nerizeni / spatnem rizeni opacny efekt.
Dalsi vec s cim maji problem lide neoplyvajici moc "soft skills" je akceptovat ze programuji lide a ne stroje. Napriklad programovani jsem se nikdy zcela profesionalne nevenoval protoze jako dislektik je pro mne 96 a 69 to same. Nebo spis vidim lip "{" a "begin" marne hledam x minut. Udelej mi neco jako ";=" nebo ".=" a nejspis vyhorim. Napriklad programatoru kteri skutecne znaji C++ bych mohl spocitat na prstech jednoho pahylu. Zbytek jsou "upgradovani" ceckari.
Jazyk ktery se snazi podchytit kazde paradigma je sice neskutecne mocny, ale take velmi narocny na nauceni. Je otazkou jestli to za tu namahu stoji. Clovek ma preci jen omezene schopnosti. Navic v rade pripadu shanis programatora ktery ma presah napr. znalosti knihoven,HW platformy, bezpecnych/failsafe postupu pri embedded vyvoji (napr. aerospace) a tak podobne. Je malo tech kteri to drzi v kesuli jeste pri brilantni znalosti C++.
A potentuji se z toho hned dve urovne. Z te komplexity se potentuji lidi co maji udelat compiler pokud mozno optimalizovany a pak programator samotny. Nerkuli jeste lidi co delaji IDE aby to byl schopen naprgat bezny komunikativni programator a ne matfyzak.
Jeho odchod celkem dobre symbolizuje upadek Pythonu jako jazyka v posledni dobe. Zmeny v core a standardni knihovne, ktere by kdysi nikdy neprosly protoze jsou v rozporu s PEP 20. Rozplizlost, jeste vetsi nekonzistence a prekomplikovanost. Referencni a ve vetsine produkcniho nasazeni jedina mozna implementace CPython pritom porad radove zaostava jak ve vykonu napr. oproti V8 a paralellnim zpracovani kvuli GILu.
Popularitu ma a jeste dlouho mit bude, hlavne kvuli ekosystemu kolem numpy, scipy a pandas, ale kodit v nem je porad vetsi opruz, hlavne kdyz jsou zkusenosti od jinud, napr. s golang.
ktere zmeny v core myslis? Zase tolik se toho prozatim nezmenilo ne (na to, jak je s nami ten jazyk dlouho) a i kdyz s nekterymi zmenami nemusim souhlasit (treba tato posledni je uz dost matouci), tak ten jazyk porad zustava dost produktivni. Vykon CPythonu je ale pravda horsi, bohudik to vsak neni jedina implementace.
Hehe, tak uz zrusili jednu "vlastnost", kterou jsou povazoval jako klicovou pythonu. Jsem zvedavy, kdy pridaji moznost ukonceni prikazu jinym symbolem nez koncem radku, kdy zrusi nutnost odsazovani a kdy pridaji symboly pro otevreni a uzavreni bloku misto stupne odsazeni. Pak z toho bude rozumnejsi jazyk.
Pak to bude jeste chtit opravit dokumentaci s priklady a nahradit blbosti typu
re.match(data)
spravnym
data.re_match()
Pak to bude konecne lepsi:-)
Hmm, jo trosku jinak. Pro regexp jsou zapotrebi dva stringy, takze spravne by melo byt varstr.match(regexpstr). Jak se jmenuje promenna objektu (data, str, varstr) je jedno, dulezite je, ze se metoda vola na objekt retezce a ne na tridu, jak uvadeji casto priklady v python ucebnicich pro zacatecniky, cili
import re
re.match(varstr,regexpstr)
coz mi pripada blby, ucit takhle zacatecniky. Ale mozna je holt problem, jak se v pythonu michaji moduly s objektama.
https://stackoverflow.com/questions/452104/is-it-worth-using-pythons-re-compile
https://docs.python.org/3.7/library/re.html#re.compile
"Note: The compiled versions of the most recent patterns passed to re.compile() and the module-level matching functions are cached, so programs that use only a few regular expressions at a time needn’t worry about compiling regular expressions. "
minimalne to bylo v Pythonu 1.4:
https://docs.python.org/release/1.4/ref/ref6.html#HDR0
takze MINIMALNE uz existuje 22 let, takze pro vetsinu ctenaru rootu "odjakziva" :)
K ostatnímu se kvalifikovaně nevyjádřím, ale úroveň bloku daná odsazením bych za přednost rozhodně neoznačil. Po mládí s Fortranem, kde špatné odsazení nemuselo vést k formální chybě, ale změnilo logiku příkazu, jsem si říkal, že když někdo někdy vymyslí něco, co se ukáže jako nešikovné, tak to stejně někdo později zopakuje.
Není to jen Python s odsazováním, napadá mě třeba další ajťácká perlička:
Pánové Madnick & Donovan napsali skvělou učebnici Operating Systems (1966). Se spoustou cvičení, samozřejmě na IBM/360. A jeden příklad uvádí: představte si, že někdo má ten šílený nápad, že udělá magnetický disk se spirálovou stopou... a má se vyřešit, zda sektory budou stejně dlouhé nebo mít stejný úhel, jak se bude vystavovat a vůbec přidělovat prostor na disku atd.
No a zanedlouho vymysleli CD, a tam je spirálová stopa a drivery musí řešit Donovanův příklad z učebnice.
Možná to líp rozveď. Nevidím v tom tu argumentaci.
V Pythonu (a také v Haskellu, CoffeeScriptu a v dalších jazicích) je prostě odsazení ekvivalentní složeným závorkám. Když to jinak odsadíš, tak je to ekvivalentní tomu, jako když by si dal jinak závorky. Není v tom žáná magie, a nedovedu si představit, jak bych se mohl splíst. Prostě jednoduše geniální.
Když jsi vytáhl staré jazyky: pamatuji si ten pocit, když jsem z prastarého Atary Basicu přecházel na Pascal. Taky jsem si říkal "ty vozo, a jak tam budu psát čísla řádek? Jako to to begin a end stačí?" No, stačí no.
Při explicitním odsazování se mi už jednou stalo, že jsem odsadil nekonzistentně s bloky – a pak jsem ladil a dlouho mi trvalo, než jsem to zjistil. Protože jsem si při čtení všímal odsazení a ne begin/end. S Pythonem by se mi takováto věc nestala, tam odsazení se bude chovat z hlediska bloků přesně tak, jak vypadá. Přijde mi to lepší než redundantní informace – jednou v begin/end nebo závorkách a jednou v odsazení.
Možná ale jen s nižšími tisíci řádků v jazycích používajících odsazení mám málo zkušeností na to, abych viděl nevýhody tohoto řešení.
V praxi to není až tak zásadní výhoda, odsazení si obvykle uhlídám, ale prostě řešení v Pythonu mi zatím přijde lepší.
Prave ze ne!:-) Prave rikam, ze ty vychvalovany vlastnosti (NL jako oddelovac, odsazeni jako formatovani bloku, nemoznost v if podmince priradit promennou) python ted zacina doplnovat, aby to fungovalo i jinak (strednik uz snad python umi, ted ten PEP 572 zavadi prirazovani v if podmince), takze jsem se jen pousmal a zamyslel nad tim, kdy jeste zavedou alternativni zapis bloku misto odsazeni.
Mimochodem, kdyz je mozne pouzit strednik jako oddelovac prikazu, jak se v takovem zapise odsadi blok? Ze by pocet mezer od stredniku? To musi byt zuzo:-) Ale jasne, python neni primarne urceny pro psani cmdline skriptiku (filtru) ala Perl:-)
Více příkazů na řádek je zhovadilost, přiřazení v podmínce taky. Bloky pomocí odsazení geniální nápad, za 5 let co pracuji v Pythonu jsem se spletl jen jednou. Programy v Pythonu se podobají psaní poezie.
Nakonec i složené závorky k oddělování bloků v C jsou zjednodušení otravného algolovského begin a end, a Python to jen dále zjednodušuje.