Názory k článku Automatický refaktoring zdrojových kódů Pythonu s využitím nástroje Pyrefact

V prvom príklade zo štvrtej kapitoly je volanie funkcie ( add_globals(1, 2)), ktorá žiadne argumenty neprijíma ( def add_globals(): ...). Vysledkom je chyba TypeError: add_globals() takes 0 positional arguments but 2 were given.

28. 3. 2024, 10:00 editováno autorem komentáře

Heh, já si tady tím lámu hlavu pět minut, říkal jsem si, jestli jsem tak blbej a už jsem skoro startoval PyCharm, že to zkusim.

ah moje chyba, já to zapoměl v článku zdůraznit - to je tam naschvál, aby se ukázalo, že Pyrefact vlastně ve skutečnosti "nerozumí" kódu v runtimu, takže podobný kód klidně zrefaktoruje, i když v runtime obě verze vyhodí výjimku.

přidáno do poznámky

přidal jsem do poznámky, proč je ten příklad uveden a že dojde k runtime chybě.

hmm zkousel to nekdo na vetsim projektu? Da se tomu aspon ramcove verit? Jako ty priklady z clanku vypadaji ok (a zrovna optimalizace smycek by byla dobra), ale jsou to jen kratky priklady.

no já to samozřejmě zkoušel, ale per-partes :-) A hlavně Pyrefactu úplně nevěřit. V podstatě postupuju tak, jak je napsané v článku - nechám si udělat refaktoring, protáhnu Blackem, zkontroluju Ruffem+Mypy a potom se až podívám, co tam Pyrefact udělal. Některé změny se akceptují, další ne.

Hm, myslel jsem, ze to nejak upravi kod do neceho, co pujde zkompilovat necim normalnim, co treba zavede zavorky a typy, aby se zprehlednil kod a hlavne, aby to nebyl typicky pythoni writeonly kod a dalo se to i cist. No a taky aby automaticky opravoval zpetnou nekompatibilitu pythonu v jednotlivych verzich (dokazete si predstavit jiny projekt nez python, ktery by diky tak nelogickym zasahum do zpetne kompatibility prezil tak dlouho?).
Dokud se nebude dat prevest python do cecka nebo proste to nejakeho normalniho jazyka, tak bude uzitecna jen ta cast na odstraneni mrtveho kodu (hadam, ze ten modul proste smaze soubory s priponou .py).
Osobne by me zajimalo jestli funguje nejaky nastroj na prevod pythonu treba do C#/Java ... teoreticky by to nemuselo byt tak slozite, protoze python ve finale toho vlastne moc neumi, ale bylo by to dramaticky rychlejsi a spolehlivejsi. Jako hloupe by to slo pres dynamic typy, ale to je samozrejme kompletne spatne, ale podle meho by to byl zacatek na opravu pythonich skriptu. Navic aspon trochu normalni lidi (nebo lidi co maji nabeh aspon na programatora a ne jen kodera) i v pythonu pouzivaji typy, takze pak by to mohlo byt fenomenalni ten prevod.

co zavede zavorky nebo dokonce prevede do Javy? Tyjo nevim, nedeje se to spis v opacnem smeru?

Lojzo, chápu, že jsi musel v životě vidět hrůzný Python, když tě to takto ovlivnilo, ale existují různé terapeutické metody jak se toho zbavit. Nás, co Python dobře živí, ti to rádi ukážeme.

Jinak mi přijde, jako bys mluvil o Perlu. Ale i Perl se dá psát krásně. Je to o talentu Lojzo. Jazyky začínající písmenem P to mají těžké.

30. 3. 2024, 10:38 editováno autorem komentáře

Ono to na první pohled složitě nevypadá, ale bohužel díky extrémní dynamičnosti Pythonu to jde dost blbě.
Na jednoduché skripty, co používají jenom standardní knihovnu, by to možná stačilo (pokud bys teda naimplementoval celou standardní knihovnu včetně věcí jako open, které nejdou rozumně otypovat).
Ale jakmile začneš používat knihovny třetích stran, tak zjistíš, že buď nejsou otypované, nebo vnitřně používají věci jako eval, dynamické předky, podmíněnou definici funkcí a podobné lahůdky, anebo jsou napsané v C/Rustu a očekávají CPythoní runtime.

Kdybys přišel s něčím rozumným (třeba s nápadem do toho pythonního kódu automaticky ty typy přidat), asi by to bylo lepší. Python s přidanými typy převod do "něčeho normálního" fakt nepotřebuje, leda snad pokud z něj potřebuješ vymáčknout lepší výkon. C není dobrý nápad skoro nikdy a kód v Pythonu do něj převádět v zájmu "čitelnosti" je fakt bizár.

30. 3. 2024, 12:04 editováno autorem komentáře

převod do jiného jazyka, to si dovolím tvrdit, že nemá moc význam (chybí stejné knihovny atd.).

Navíc to není úplně dobře možné, protože typový systém Pythonu je dost odlišný, než například v Javě (ať jde o základní typy, např. long, což by se ještě dalo nějak ohnout, tak hlavně problém variance, kde to má Java blbě, ale hlavně jinak, než Python).

Jinak s Mypy+Monkeytype (automatické doplnění typů) atd. se dá s Pythonem dost dobře vyžít.

Tak jako samozrejme, ze by se musely hierarchicky prelozit vsechny zavislosti, ale ono vetsina pouzitelnych knihoven, ktere skutecne neco delaji, je stejne primo v Ccku, aby to nebylo silene pomale.
Jako ja s Pythonem zil na linuxu (serveru) dlouho .... jako na vyber bylo bud C nebo bash a nebo python. O bashi se radeji nebudu ani vyjadrovat a v Cecku na linuxu neco delat je taky dost opruz. Tak jsem ruzne instalacni skripty delal v pythonu. V te dobe 2010 to byla bomba. Nicmene jak sel cas a objevil jsem .NET Core, tak uz proste IMHO nema python fakticky duvod existence.
Jako z praxe vim, ze nejhorsi je, ze python=excel ... kazdy to ma v CV, ale nikdo ani s jednim neumi a pouziva ho na veci, na ktere by nemel. Ono koder!=programator, to je bohuzel trvrda realita. Neco nakodit v jakemkoliv jazyku umi uplne kazdy .... ale programovat, to je pak tezsi. Problem pyhonu vidim v tom, ze lidi se s nim snazi programovat, pritom je to skriptovaci jazyk. Jako moje primarni je nyni VS + C#, asi neni nic univerzalnejsiho a pohodlnejsiho, podle mych zkusenosti. A to je proste vyvoj nebe a dudy .... v pythonu je to proste opruz. Nicmene, SAMOZREJME, ze na zakladni skriptovani ho pouzivam, ale problem je, kdyz v tom nekdo zacne programovat, misto skriptovani .... diky absenci typu a kodu, co ma vic jak 50 radku, je to fakticky write-only necitelny bastl, pokud nekdo fakt poctive nekomentuje kazdy druhy radek. Jako asi neni treba polemizovat nad tim, ze dynamicke typovani je proste nesmysl, zpomaluje beh, nic nezjednodusuje, ale prave naopak .... proto vubec netusim, proc s tim kdy kdo prisel (jako fakt me nenapada jediny duvod). Prace v teamu, nejake moduly atd. je nulova, zvlast kdyz jsou jednotlive teamy vic a min diletantske, tak nikdy nic spolu nefunguje. A pak je tam ta zpetna kompatibilita, kdy se s minoritni verzi dokaze vse rozbit ... takze venv a tahani si celeho runtimu s sebou, idealne v kontejneru, takze zadne sdilene DLL, proste totalne neefektivni jak na vykon, tak na pamet.
Co me fascinuje to, ze prisli s tim odsazovanim a co jsem naposled zkousel nejakou verzi (je to uz davno), tak stale umoznoval kombinovat taby a mezery, takze to je takovy smesny easter egg, kdy se da kod ucinit opravdu necitelnym. I basic mel begin-end .... vsechno ostatni na svete ma zavorky, jen python ma odsazeni, kde dokazete jednou mezerou zcela zmenit beh programu, cili je to nebezpecne, to je ostatne i duvod, proc byly kdy encapsulatory logickych casti vynalezeny.
Jako dnes asi jedine s type hintama (fakt podtrhuje zvracenost a nejednotnost pythonu a jeho autora, ze hinty jsou basic notaci, misto ceckove, pritom samotny python a drtiva vetsina knihoven je v cecku, jen proste aby autor ukazal, ze si muze udelat co chce - to je jedna z brutalnich nevyhod, ze je to stale fakticky onemanshow bez nejakeho industry standardu a je opravdu k placi, kolik lidi to pouziva), aby treba i to VS nebo jine IDE vedelo a davalo hinty typu a clovek nemusel u pythonu mit otevrenou prirucku.

No vidíš. A přesně jako v C nebo jiném jazyce je Python čitelný podle toho, kdo kód psal. V Pythonu existuje spoustu let PEP8 a různé nástroje, které podle něj kód automaticky zformátují - žádný "easter egg" pak nehrozí. Komentovat každý řádek je potřeba úplně stejně jako v jiných jazycích - pokud člověk používá čitelné identifikátory a neprasí, nevíc používá typové anotace (kde jsem rád, že nejsou ve stylu C), je programování v Pythonu fakt pohoda. Celý Tvůj hate se dá pak shrnout na "kód v C stylu je pro mě čitelnější", což je věc, které rozumím. Znám lidi, kterým se líbí Go a nesnesou Rust a naopak. Jsou lidi, kterým Lisp přijde super a jiní z něj rostou. Je to v hlavě, není to nic obecně platného, každý máme jiný mozek a s každým nástrojem je navíc třeba se naučit dělat věci tak, jak on to vyžaduje a umožňuje.

nase code base jsou tisice (mozna uz desetitisice) radku v Pythonu a porad je to jak citelne, tak i udrzovatelne (a to je hlavni). Jasne, chce to stabni kulturu, mit na CI nasazeny lintery a tak, ale ta "bolest" pro vyvojare je naprosto minimalni (stejne jim to naformatuje o okomentuje IDEcko).

Re rozbiti minor verzi knihovny - mas neco konkretniho? Tedy ano, zazil jsem to, ted napriklad llama-index neco rozsekala dokonce po zvyseni patch verze - ale to jsou matlaci autori te knihovny. A podobne jsem to zazil v Go, ale fakt jen malokrat.

Ale Pythonu fakt chybi nejake hodnoceni kvality knihoven a jejich tranzitivnich zavislosti. Takze JE mozne si do projektu dotahnout nejakej bastl a pak s tim je nutny zit, coz kazdeho trapi. To souhlas.

Jasný, na psaní kódu je Python v pohodě.
Ale strašně blbě se refaktoruje. Věci jako "find usages" nebo "rename" nefungujou v žádném IDE spolehlivě. U malého projektu jako máte vy ("tisíce, možná desetitisíce řádků" není zrovna moc) to ještě tolik nevadí, protože ho člověk může mít celý "v hlavě", ale čím větší, tím to začíná být horší peklo. A efektivita vývoje pak najednou jde strašně dolů.

Pokud někdo nezažil vývoj v jazyce, kde tyhle věci mají plnou podporu IDE, tak chápu, že to třeba bere jako nutnou daň za větší projekt. Ale já si pamatuju, jak fungovala Java v Intellij Idea na projektu, co měl statisíce řádků - dáš "Rename" nějaké věci a ono ji to přejmenuje správně a všude a můžeš se na to 100% spolehnout. Dáš "Find usages" a najde ti všechny a bez false positives. Tohle hrozně urychluje práci a Python to nemá.