Jako popravdě mám z toho smíšený pocit. Na jednu stranu je fajne, jak se Python vyvíjí a nepřešlapuje na místě. Na stranu druhou už to není ten snadný jazyk, jak býval někdy okolo Pythonu 2.x nebo i 1.6 (a teď se podržte - viděl jsem tuto verzi používat!). S novými konstrukcemi, možností zápisu datových typů, teď ještě novými operátory (Walrus operátor asi začátečníky dost zmate) a tak...
Vidím to podobně, Python jde cestou C++, "feature creep as a feature". Věta There should be one – and preferably only one – obvious way to do it už dávno neplatí.
30. 8. 2022, 10:07 editováno autorem komentáře
Pohybuji se na rozhraní dvou světů - "velké" IT, tedy firmy, které mají velké IT oddělení a mohly si dovolit migraci už dávno (a někdy to dost bolelo). A potom malé firmy, co mají nějaké aplikace kdysi udělané v Pythonu 2 (různé reporty atd.) a tam prostě nejsou peníze a hlavně vůle s tím něco dělat - jen vždycky někdo něco do skriptu přidá, ale migraci na Python 3 si nelajzne. Takže tam se udržují prastaré Pythony 2.
To samozřejmě chápu, ale Python 2 je legacy jazyk se všemi důsledky. Navíc ta migrace není nijak nezvládnutelná ani v menších firmách, ale chce to rozumně naplánovat a rozfázovat. A mít člověka, který skutečně umí Python a ví, co se mezi v2 a v3 změnilo, ale to se dá víceméně řešit pár hodinami času externisty.
Klicove je nejaky cas udrzovat zpetnou kompatibilitu a testovat pomoci tox na obe verze pythonu.
Prepsat rovnou do idiomatickeho 3, tak ze je to nekompatibilni s 2, je u vetsiho projektu temer nemozne, protoze nemuzete prepisovat po castech bez rozbiti projektu.
30. 8. 2022, 23:15 editováno autorem komentáře
Ja som fortran IV ani fortran 66 nepoznal, ale bol som len donuteny na skole naucit sa fortran 77 a pisat v tom programy (numericka matematika). Potom, po par rokoch, som sa nahodou dostal na forum https://www.tek-tips.com/threadminder.cfm?pid=214 a tam som sa prvy krat stretol s fortranom 90/95. Spociatku som myslel jak hnusny je ten novy fortran oproti klasike 77, ale prechod bol uplne plynuly a bezbolestny. Teraz uz ani nejako neregistrujem ci pisem vo fortrane 77 alebo 90.
Myslíš něco podobného? Někdy se to hodilo :D ... Takovej chudej swich
def update(self, action: Action) -> 'Machine': """ Update the machine state. """ state = { (State.CLOSED, Action.OPEN): State.OPENED, (State.OPENED, Action.CLOSE): State.CLOSED, ... }[(self.state, action)] ...
31. 8. 2022, 16:16 editováno autorem komentáře
Ale to prechazels odjinud. Takovy zacatecnik asi muze byt zmateny. ale popravde nevim, protoze tady se decka (15 a 17 let) sice uci Python, ale nekde na urovni puvodniho Pythonu 1 :-) - tedy zadne list comprehensions, pochopitelne vubec nic s typovou anotaci, zadne f-stringy, bodudik do nich ani necpou OOP
Osobně mi přijde, že nejproblematičtější oblastí je formátování řetězců - teď máme (pokud mi něco neuniká) 4! způsoby jak formátovat řetězec standardními prostředky Pythonu:
1. Klasický C přístup s %
2. Rust-like formátování s .format()
3. f-string
4. Template strings
To je docela přehnané, podobně zbytečná mi přijde i dualita používání jednoduchých a dvojitých uvozovek.
Walrus operator má v zásadě hlavní hodnotu v list comprehensions a generator expressions. Používat se ale nemusí, jak píšeš.
Python má vyše 30 rokov. Je pochopiteľné, že sa autori rozhodli pridať nejaké nové prvky z iných jazykov. Ja to kvitujem. Trebárs ten fstring je jedným z najlepších a najprehľadnejších riešení aké poznám. Tie ostatné sú historickým reliktom; programátori nie sú nutení poznať/používať všetky spôsoby. V C# je to podobne; tam je tých vylepšení na mraky.
Nik nedokáže navrhnúť jazyk hneď perfektne na prvý krát.
Klasický zastaralý C přístup s % doporučuju nepoužívat. F-stringy jsou super na krátké formátované řetězce. Na delší řetězce nebo řetězce, které obsahují hromadu výpočtů, používám pro lepší čitelnost metodu format(). Template strings jsem dosud neznal. Zdá se, že mají úzce zaměřené použití.
V 99 % času používám jednoduché uvozovky. Jen výjimečně použiju dvojité právě v f-stringu: f'Mlíko stojí {mliko["cena"]} Kč'
Tak ziadny jazyk nie je pre lamy, teda ak v nom maju programovat. Programovanie je o mysleni, nie o pouzitom jazyku.
Akoze explicitne pretypujete nieco co netreba? To ale nie je problem s pythonom, nespravne explicitne pretypovanie by robilo neplechu ajv inom jazyku. Ako nie ze by bolo explicitne pretypovanie v niecom na skodu. Oproti implicitnemu pretypovaniu si to takmer kazdy vsimne pri codereview.
> Akoze explicitne pretypujete nieco co netreba?
Ne, prostě například vyklopím slovník pomocí json.dumps(), chci ho poslat pomocí ZeroMQ sock.send_multipart(), a ono to spadne že send_multipart chce bytes ale json.dumps vyrobilo string. Tak tam napíšu json.dumps(foo).encode("ascii") a funguje to. Tak proč se tohle nemohlo udělat samo.
> Tak proč se tohle nemohlo udělat samo.
Pokud by ZeroMQ usoudilo, že by mělo jako argument funkce send_multipart přijímat i stringy, tak jim stačí přidat jeden nebo dva řádky: if isinstance(msg, str): msg.encode()
. A udělalo by se to z pohledu uživatele "samo". To, že tam tuhle fíčuru nepřidali, svědčí o tom, že to nedává smysl.
Bajty jsou fundamentálně něco odlišného než stringy a nejde mezi nimi nerozlišovat. Kdyby například výstup z funkce byl v bajtech, tak pro string musím zase otravně volat result.decode()
. Jako by se to nemohlo udělat samo... Ale co když je výstupem funkce JPEG obrázek? Nebo data videohovoru?