Sebastian Buczyński To też ten kod generowany przez LLM-y, ja bym powiedział, że nie jest production ready bez dodatkowych instrukcji. Widać przez ramię, że to nie jest pythonowy kod, tylko ktoś pisze Jave w składni Pythona.

Szymon Warda: Około połowa ma mniej niż 2 lata doświadczenia z Pythonem, więc to jest skala tego po prostu jest straszna. Ale też dobrze. Gratulacje, że tak powiem.

Łukasz Kałużny: Wiem o czym mówisz, o tak, jak gdyby miałem okazję chwilę popracować w projektach pythonowych, to był też dla mnie taki osobisty szok.

Sebastian Buczyński Ale no tak to obecnie wygląda. Nawet jeśli Python się gdzieś tam wbija na salony albo w jakichś szerszych zastosowaniach się pojawia, to jeszcze nie odbija się to w żaden sposób na samym języku. Plus sam język nie ma ambicji, żeby być uruchamiany na lodówkach.

Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Linki do tego odcinka góra, dół, Chat, Claude, cokolwiek, znajdziecie, ogarniecie, wierzymy w Was, mądre chłopaki i dziewczyny z Was są. Dobrze, parafialki Łukaszu. 16 czerwca, słyszałem, że coś fajnego się dzieje w Warszawie. Kojarzysz, co? O co chodzi?

Łukasz Kałużny: Tak, Szymon będzie występował w stroju dinozaura, jeżeli się nie mylę. Albo jak odpowiednio zasubskrybujecie lub polajkujecie, a najlepiej wpiszcie komentarz: Szymon ma być dinozaurem.

Szymon Warda: Co więcej, może będzie nawet strój do przymierzenia, żeby sobie fotę zrobić.

Łukasz Kałużny: Dobra, to zerknijcie również na Patoarchitekci.io/szkolenia, na te pozostałe na najbliższy rok szkolny. No i co? Dzisiaj przejdziemy sobie do odcinka o stanie Pythona i ekosystemu.

Szymon Warda: Tak. A z kim?

Łukasz Kałużny: Z Sebastianem. Cześć Sebastianie. Kiedy zapytaliśmy naszych słuchaczy, z kim warto porozmawiać o stanie Pythona, to byłeś główną wskazywaną osobą. Taką można powiedzieć, że dość jednogłos, jak tak rozrzuciłem kogo właśnie zaprosić, żeby porozmawiać o tym jak wygląda teraz Python. I takie rozgrzewkowe pytanie jakbyś się przedstawił komuś, kto cię nie zna właśnie? Dlaczego tak ludzie mogli Ciebie zarekomendować?

Sebastian Buczyński Ok, więc ja jestem osobą, która łączy światy inżynierii oprogramowania i Pythona. Jestem zaangażowany w życie społeczności od wielu lat, głównie przez udział w konferencjach, lokalnych meetupach. Lubię też jeździć po Polsce czy kiedyś bardziej po świecie na różne pythonowe wydarzenia. I tak jak wspomniałem, właśnie staram się łączyć ten świat inżynierii, bo no nie ukrywajmy, wiele jednak wyzwań jest agnostycznych technologicznie. I ja taką misję sobie postawiłem kilka lat temu, żeby dobre rzeczy, które się da zaadaptować do Pythona, ale bez upodobnienia go do Javy na przykład, należy przenosić i stosować, bo jak wspomniałem, te wyzwania są po prostu uniwersalne. I tę misję realizuję między innymi pracując z Bottegą właśnie, specjalizując się w Pythonie czy występując na różnych konferencjach, wydarzeniach, biorąc w nich udział. No i też zdarzyło mi się napisać książkę, która dokładnie jest poświęcona realizacji wzorca czystej architektury w Pythonie.

Szymon Warda: O, to będzie ciekawie z tą czystą architekturą. Dobrze, Łukasz trochę Cię rozgrzał w kontekście kim jesteś. A ja mam pytanie takie trochę na strzał pierwsze. Python jest fenomenem, bo to jest język, który tak naprawdę jak się załóżmy spojrzy na Index TIOBE-a, czyli popularności języków, język, który w 1994 roku był na 21 miejscu i od tego czasu po prostu bardzo powoli i miejscami tak naprawdę cały czas rośnie. I to jest chyba fenomen na skali języków tak naprawdę, który tylko praktycznie rośnie. Co jest powodem, że Python rośnie? Co czyni go takim wyjątkowym? Twoim zdaniem oczywiście.

Sebastian Buczyński Powodów jest wiele. Jakby z mojej perspektywy, też osoby, która używa języka od już nastu lat, przede wszystkim zastosowania w data science i machine learning bardzo mocno pompują te rzeczy. To też widać na przykład po zdarzeniach, po konferencjach, które albo mają osobne ścieżki typowo pod te tematy, albo to są osobne jakieś takie satelickie wydarzenia dookoła. No i stety niestety, ale no tacy web developerzy jak ja typowi nie mają zbyt dużo tematów do rozmowy z tymi ludźmi. Natomiast niewątpliwie jest to kolejna społeczność, która z boku rośnie. Ale to jest oczywiście tylko jeden z powodów, bo też Python jest jeszcze używany szeroko w edukacji. No i ostatnio, co w zeszłym roku padło podczas panelu na Euro Pythonie, jest też masa ludzi, która wchodzi teraz do Pythona jakimś PoC-iem, dlatego, że snippety kodu z AI są często właśnie generowane w Pythonie, więc również jest taki przypływ ludzi.

Szymon Warda: Tak żeby w ogóle dać wartości temu, co Ty mówisz, to jest tak, około połowa ma mniej niż 2 lata doświadczenia z Pythonem. Więc to jest skala tego, po prostu jest straszna. Ale też dobrze. Gratulacje, że tak powiem.

Łukasz Kałużny: Dobra, to słuchaj, ja zacznę, teraz sobie jedną rzecz przypomniałem, kiedy miałem pierwszą styczność z Pythonem słuchajcie, jak bardzo dawno. Więc pamiętam dyskusję o pierwszym Python 3000. Sebastian pewnie już kojarzy, jak bardzo to był stary ten. Poczułem się. Sprawdziłem, który to był rok i to nie wygląda dobrze. Ale słuchaj, jedna taka rzecz, która też się pojawiła, jak powiedzieliśmy, że będziemy z Tobą nagrywać odcinek, tu jest pytanie od Oskara i w sumie ono świetnie, jak ja oglądam jako osoba, która wskakiwała sobie, co jakiś czas miała po prostu takie chwilowe wejście do Pythona. Był ten Zen of Python kiedyś, że jest, był ten sławetne powiedzenie: One obvious way to do it. I czy to w ogóle jeszcze ma rację bytu w dzisiejszych czasach? Bo dla mnie, teraz tak patrzę, ten wątek potem też zahaczymy, ale mamy ileś package managerów, checkerów, interpreterów, n sposobów na asynci, free trading. I teraz, bo pole wyboru, które się pojawiło, zaczyna przypominać JavaScript, Javę, .Neta, jeżeli wiesz o co chodz, ta wolność, która się pojawiła. I trochę chyba te zen uciekło moim zdaniem. Nie wiem jak Ty na to patrzysz?

Sebastian Buczyński Tak, krótko mówiąc zdecydowanie się to rozmyło i dzisiaj jest to chyba taki, nie wiem jak to się mówi, apokryficzne źródło, na które tylko najbardziej zapalczywi użytkownicy języka się czasem powołują. Ale uważam, że przykłady, które podałeś nie są może najtrafniejsze, bo akurat kwestie na przykład package managerów to ja bym to określił mianem takiego dynamicznego wzrostu i dużo jest eksperymentów i jednocześnie pojawia się za tym też jakaś standaryzacja. Bo na przykład mamy cztery package manager powiedzmy, każdy ma inny format. Jak ostatecznie ten plik z zamrożonymi zależnościami wygląda? I to też zostało całkiem niedawno ustandaryzowane. Więc to bym traktował z takim jeszcze, jakbym brał, ze szczyptą soli, że tak powiem, po polgliszowemu. Ale nawet w samym języku, nawet jak się na sam język spojrzy, bo pamiętam był też określany mianem, że łatwo jest z nim zacząć, trudno jest go opanować w pełni. I to się stało jeszcze bardziej skomplikowane między innymi dlatego, że jest właśnie wiele rzeczy, które daje nam po prostu alternatywy do zrobienia czegoś. I to jest tak, że nawet ja, wertując gdzieś tam dokumentację, jestem w stanie trafić na jakąś ciekawostkę, o której sobie nie zdawałem sprawy i okazuje się, że to ma jakieś jedno niszowe zastosowanie, nie wiem, w jednym procencie przypadków. I dużym wyzwaniem stało się też uczenie Pythona nowych ludzi na takim poziomie, żeby znać coś więcej niż tylko podstawy podstaw, bo również padają słuszne, uzasadnione pytania: a czy mi się to przyda? Przyda Ci się, ale nie tak często jak bym chciał. Czyli nie tak często jak usprawiedliwiałoby to, żeby nie wiem, pakować to w kurs podstawowy i tak dalej. Więc tych sposobów realizowania rzeczy jest masa. Natomiast ja uważam, że one wszystkie są uzasadnione. Jak nawiązałeś do asynca, to ja bym poszedł nawet trochę szerzej o w ogóle robienie jakiejś współbieżności czy concurrent w Pythonie, bo tych sposobów jest dużo po prostu. Niesławne wątki, subprocesy, teraz mamy subinterpretery, od jakiegoś czasu asyncio, które też tworzy.

Łukasz Kałużny: Sebastian, to może wątek jeszcze za chwilę, bo mamy na to oddzielne pytania, więc może w tym. To akurat jako właśnie przykład, ale… Czyli patrząc się to jest taka naturalna ewolucja tego, że ten język jest tak szeroko używany w tym momencie już.

Sebastian Buczyński Trochę tak, ale z drugiej strony też wpływa na to może sam sposób zarządzania Pythonem czy jego ewolucji. Bo mamy te dokumenty Python Enhancement Proposals, czyli takie oficjalne propozycje tego, co w języku zmienić, co dodać. I też jak się popatrzy wstecz, jest masa właśnie takich rzeczy, które dodają jakiś nowy syntax sugar albo jakąś nową funkcję do języka i tak dalej. I one mocno rozdmuchują tę taką wiecie, to, co jest w bibliotece standardowej, to, co jest dostępne, jak składniowo na przykład niektóre rzeczy zrealizować. Już nie ma switcha nadal, ale jest pattern matching i on też ma dużo różnych zastosowań,

Szymon Warda: więc… Który kiedyś był bardzo popularny w ogóle w językach funkcyjnych i tak dalej. Teraz się rozszerzył na języki, powiedzmy sobie obiektowe. Dobra, ale wiesz co? Tak trochę właśnie nawiązując do tego, co powiedziałeś odnośnie wątków i w sumie najstarszego dowcipu i takiego prześmiewczego powiedzmy podejścia, o którym Ty w ogóle masz też swoją prezentację. No to Python zawsze słynął z tego, że ok, z jednej strony stosowany jest w językach, zastosowaniach bardziej machine learningowych, gdzie mamy dużo danych, mamy co liczyć, a z drugiej strony Python jako taki zawsze był wyśmiewany jako ten wolny język, no nie. Więc jak to połączyć i jak ten obecny status, jeżeli chodzi właśnie o wydajność Pythona i co tam się w ogóle dzieje? Takie trochę większe pytanie bym powiedział.

Sebastian Buczyński Ok, to ja postaram się je rozbić też na dwa, bo kwestia wielowątkowości i wydajności jest ciut ortogonalna. Więc tak, może wspomnę na początek o tym, że ogólnie to Python jest starszy niż Java. Ma 35 lat, już ponad teraz, co też niektórych zaskakuje, więc staram się to powiedzieć. I wydajność Pythona tak, jest rzeczywiście niska i ja ze swojego punktu widzenia, bycia przez pewien czas architektem, w wielu zastosowaniach nie ma z tym problemu. Więc takie było podejście przez wiele lat, że no dobra, jest wolno, ale ogólnie jest wystarczająco szybko, więc my z tym nic nie robimy. Jak mamy, nie wiem, zastosowania typu obliczenia numeryczne, to są biblioteki Nampa zaimplementowane w innych językach, między innymi C, po to, żeby te rzeczy były wydajne. I taki stan rzeczy się utrzymywał przez wiele lat, absolutnie nie byłem też z tego osobiście zadowolony. I kilka lat temu była, znaczy jest nadal taka inicjatywa Faster CPython, której celem było zwiększenie wydajności języka. Taki ambitny cel, że przez pięć kolejnych wydań od 3.10 do 3.15, żeby ta wydajność wzrosła pięciokrotnie. Mamy wersję 3.14 wydaną w październiku i na razie jesteśmy na 20-40 punktach procentowych, więc trochę jeszcze brakuje. Ale sam fakt bycia takiej inicjatywy no już o czymś świadczy. I teraz pod tą inicjatywą jest tak naprawdę kilka różnych rzeczy. Po pierwsze, mamy różne jakby podstawowe przeróbki, może w tym, jak interpreter działa, bo on okazuje się jeszcze do niedawna też częściowo działał w oparciu o wyrażenia regularne. Więc zanim w ogóle można było pomyśleć o bardziej zaawansowanych technikach optymalizacji, just in time compiling, to trzeba ten cały śmietnik było trochę uporządkować i ucywilizować. I to są zmiany właśnie w tych poprzednich wydaniach, w dużej mierze pod tym kątem. Więc tak, dostrzeżono, że jest problem i że należy go rozwiązać w tym podstawowym interpreterze. Bo wiadomo lub nie, ale istnieją też alternatywne implementacje Pythona. Był kiedyś IronPython napisany w CSharpie. Był Jython napisany w Javie. Oczywiście jest RustPython teraz. Nawet sprawdziłem sobie jakieś commity do niego ostatnio, bo Iron i Jython już dawno są opuszczonymi projektami. No i był też ten Python napisany w Pythonie, czyli PyPy. I każdy z tych projektów zarówno był szybszy jak ówczesna wersja interpretera, jak i też nie cierpiał powiedzmy przez to ograniczenie wykonywania tylko jednego wątku w danym czasie. Natomiast w społeczności i w samym języku jest zbyt duża trauma po tym, jak wydawany był Python w wersji trzeciej, który zrywał z kompatybilnością wsteczną, bo pewien design choice był nieoptymalny.

Szymon Warda: Pamiętamy.

Sebastian Buczyński Tak, że nikt na pewno się nie zdecyduje na to, żeby zastępować interpreter Pythona innym. A nawet jakby tak było, to adopcja będzie szła z pewnością jeszcze wolniej niż to, co mieliśmy przy okazji przejścia z Pythona 2 na 3. Zresztą niedawno wyszedł taki dokument na YouTubie “Python Documentary”, który też opisuje fajnie te historie właśnie, co się w języku zmieniało i jak zima zaskoczyła drogowców, metaforycznie mówiąc, jak odpowiedzialne osoby za Pythona były zaskoczone, że tak duża już adopcja jest języka i jak dużo problemów jest z tym, żeby przejść z tej wersji drugiej na trzecią. Więc dobra, koniec dygresji. Wydajność Pythona. Tak, więc same optymalizacje i sprzątanie w interpreterze postępuje. Przez kilka lat mieliśmy zespół trzyosobowy bodajże w Mecie, były to 3 osoby pod przewodnictwem Marka Shannona, które pchały tę inicjatywę plus jeszcze kontrybucje z zewnątrz oczywiście paru innych osób. No i niestety ten zespół w Mecie został zredukowany w ubiegłym roku, bodajże w maju, jak tam przetaczała się fala redukcji. No i teraz ten projekt dalej jest kontynuowany, tylko już w takim typowo community driven, poza jakby Metą. Więc tak, jeśli chodzi o taki duży obrazek. Czy może jakieś pytania? Bo ta historia jest dość długa, wielowątkowa i możemy skręcić wątki zaraz właśnie.

Szymon Warda: Wiesz co, wydaje mi się, że to może być dobry moment na wyjaśnienie właśnie o co chodzi z wątkami, bo to jest ciekawy pomysł i on też pokazuje różnorakie podejście do problemów, ale też pokazuje według mnie, ale z boku kompletnie, jak społeczność stara się rozwiązać problem Pythona bez… Jednocześnie niektóre podejścia są takie ok, żeby wszystko działało nie ma problemu. A drugie podejście znowu jest takie, że no jednak sorry, ale wszyscy będziemy musieli wspierać pewne podejścia. A że podejścia są cztery, to jest też fajny moment na wyjaśnienie, jak w ogóle do tego się podchodzi. No bo Python jest takim trochę unikatem. Ja jeszcze pamiętam, że FSharp jeszcze miał dwa podejścia zupełnie różne. Więc jak to wygląda i o co chodzi?

Sebastian Buczyński Ok, więc w ogóle najpierw o tych wątkach, o GIL-u tak zwanym i tak dalej. GIL to jest akronim od Global Interpreter Lock i to jest taki świadomy powiedzmy design choice w języku dawno temu po to, żeby było prościej. Jest wsadzony po prostu mutex w sam środek interpretera i on jest zajmowany przy wielu różnych okazjach, między innymi tam garbage collectingu i tak dalej, i tak dalej. W praktyce oznacza to to, że dwa wątki równocześnie nie mogą w Pythonie wykonywać kodu na CPU. Kilka wątków może czekać na IO, z tym nie ma problemu, ale w danej chwili kod interpretera wykonuje tylko jeden wątek. I podejść później do rozwiązania albo obejścia tego problemu pojawiło się kilka. Więc chyba historycznie najstarszym, albo przynajmniej takim, który na pewno osiągnął dojrzałość w języku, to jest asyncio. Czyli to jest taki model współbieżności, który mamy na przykład w NodeJS czy w ogóle w JavaScripcie. Czyli jest to programowanie kooperatywne, gdzie żeby jeden powiedzmy tak zwany współprogram przekazał sterowanie innemu, no to musi użyć słowa kluczowego odpowiedniego, żeby kontrolę oddać. Dzisiaj używamy awaitów, wcześniej to był yield, ale to było tylko jedno wydanie Pythona i nikt już jakby o tym nie pamiętał. Mówię oczywiście o yield promise. To jest pierwsza rzecz. Natomiast to podejście asyncio, jak trochę nazwa podpowiada, ono się nadaje tylko do kodu, który jest I/O bound. Czyli oczekujemy na odpowiedź z bazy danych, wysyłamy żądanie do innego serwisu i tak dalej, czekamy kilka sekund. Z założenia ten CPU się nudzi w trakcie wykonywania tego programu. Czyli to nie jest rozwiązanie problemu GIL-a, tylko to jest dodatkowy paradygmat, który dorzucony był do języka i w części zastosowań pozwalał po prostu to ograniczenie ominąć. Natomiast żeby nie było tak, że to był jakiś wynik prokrastynacji i po prostu dorzucono do języka coś, że taki ochłap, to istniały już wcześniej frameworki, które w jakiś sposób też taki feature do języka dodawały, tylko po prostu zostało to zrobione jeszcze raz w standardowej bibliotece. Więc to jest podejście numer jeden. Wspomniałem o tych alternatywnych implementacjach Pythona, to też były jakieś, można tutaj zahaczyć, bo ponieważ one były zaimplementowane zupełnie inaczej, to po prostu GIL-a nie miały. Ale znowu nie zdobyły żadnej adopcji bardziej znaczącej i tutaj trend był tylko spadkowy od któregoś momentu. I mamy free trading. I na koniec jeszcze jeden temat, o którym za chwilę, Free trading to jest, od poprzedniego wydania Pythona takie wydanie, które zastępuje ten jeden globalny mutex mniejszymi blokadami i używa jeszcze paru innych wyrafinowanych technik. Bo trzeba powiedzieć, że to nie jest pierwsze jakby podejście, dlatego że jak to, to Python jeden wątek wykonuje naraz? To nie próbowaliście coś z tym zrobić? Próbowało wielu i wszyscy polegli. Pierwsza próba w ogóle jest 1996 roku, gdzie Greg Stein zastąpił właśnie jeden ten globalny mutex kilkoma mniejszymi. I wszystko fajnie, wątki działają równolegle, ale kod jednowątkowy działa dwa razy wolniej. To jak już jesteśmy wolni, to teraz nie zrobimy się dwa razy wolniejsi tylko po to, żeby mieć kod wykonywany wielowątkowo. A potem była kolejna próba, używała bardziej wyrafinowanych technik, bodajże Larry Hastings Gilectomy to się nazywało. I podobny rezultat, czyli tak, jest wielowątkowo, jest to większe wyzwanie inżynieryjne, ale dalej ten kod jednowątkowy był wolniejszy. I w końcu wiele lat później Sam Gross stworzył takiego PoC-a bardzo rozbudowanego, który wykorzystywał jeszcze więcej, jeszcze więcej wyrafinowanych technik, właśnie przez zmianę sposobu garbage collectiingu, jakąś tam inteligentniejszą alokację pamięci, jakiś ownership wątków nad obiektami i tak dalej, i parę innych takich drobnostek, które spowodowały w końcu, że ta kara wydajnościowa dla jednowątkowego Pythona była już taka kilkuprocentowa, już była do zaakceptowania. I znowu nie jest to domyślny tryb teraz w Pythonie, bo teraz tak. Potem z tego PoC-a Sama wyniknęło to, że powstał z tego dokument. I nie, jakby ten post nie został wmerge’owany do Pythona, ale jego części oczywiście zaadoptowane, przeniesione. I mamy teraz możliwość albo skompilowania Pythona w trybie, który wykorzystuje ten nowy tryb działania, albo możemy ściągnąć binarkę tam używając narzędzi jak UV, o którym pewnie za chwilę jeszcze sobie porozmawiamy i w ten sposób możemy mieć bezwątkowe. I to jest jakby stan obecny. Oficjalnie 3.14 wersja, jest to wspierany build Pythona, co znaczy, że zostanie to na dobre i na złe przez przynajmniej kilka lat w CPythonie. Jest jeszcze ostatnie podejście, które polega na tym, że zamiast coś pomiędzy wątkami a procesami, że uruchommy zamiast wielu wątków, uruchommy wiele kopii interpretera Pythona. Czyli tak jak musieliśmy chronić, nie wiem, wewnątrz interpretera jakieś struktury krytyczne, co powodowało użycie tego samego mutexu przez różne wątki, to teraz posiadajmy różne kopie tego samego całego stosu. Czyli nie mamy współdzielonej pamięci tak wprost. Ale znowu, jest to jeszcze jeden paradygmat, który też został w międzyczasie dołożony.

Szymon Warda: Takie trochę procesy można powiedzieć. Dobra, czyli mamy różne modele, ale tak naprawdę to, bo mówiłeś, że przez wiele lat właśnie ta wydajność Pythona nie była problemem. Bo Python w sumie w wielu przypadkach to to jest wrapper do wywołania różnych bibliotek w C, powiedzmy sobie, albo takich mocno zoptymalizowanych. To kiedy wydajność Pythona staje się realnie problemem tak naprawdę obecnie?

Sebastian Buczyński To teraz tak, konkretne przypadki, które zainspirowały na przykład tą ostatnią wydajność, są opisane w PEP 703 i tam podawane są na przykład przykłady, w których jest to kod uruchamiany gdzieś tam w kontekście machine learningu i rzeczywiście chcieli wykorzystywać wielowątkowość. Znowu to jest trochę ortogonalne do wydajności, ale był to konkretny problem, w którym akurat zastosowanie wielowątkowości rozwiązałby problem z wydajnością. I nie mówimy tutaj o wydajności języka per se, tylko problem, który akurat był zrównoleglany. No i jeżeli użylibyśmy procesów tak jak się to robiło do tej pory, to po prostu zużycie pamięci jest zbyt duże i nie da się tego zrobić. A tak bardzo ogólnie odpowiadając kiedy jest problemem wydajność? To moim zdaniem z punktu widzenia takiego architektonicznego, to jest wtedy, kiedy mamy odpowiednią skalę i mamy jakieś wymagania, jakieś SLO na opóźnienie, na wykonanie operacji i po prostu się w tym nie mieścimy. I to nie ulega wątpliwości, że język jest wtedy jakimś bottleneckiem, który jest problematyczny do przeskoczenia, jeśli chodzi o takie czyste operacje.

Łukasz Kałużny: Dobra Sebastianie, to zejdźmy teraz trochę z low levelu i wejdźmy na rzecz, którą dotyka developer experience. I w sumie tak patrząc z perspektywy projektu, mamy ten projekt UV i Ruff od Astrala, które teraz, to jest moja perspektywa, że w ostatnim czasie bardzo mocno zaczęły być nie wiem czy standardem, czy normą, ale weszło, tak te 2 rozwiązania weszły z buta, że tak powiem, trochę patrząc na to. Jakbyś powiedział, przybliżył w ogóle czym są te narzędzia, co rozwiązują i jaka jest twoja właśnie opinia i perspektywa na to?

Sebastian Buczyński Tak, więc UV i Ruff to jest trochę dowód na to, że przynajmniej w niektórych kontekstach wydajność może być featurem albo może być przewagą konkurencyjną, zwłaszcza w takim świecie jak Python. UV to jest manager pakietów, który pozwala doinstalowywać paczki, zamrażać drzewo zależności, aparat dodatkowo wbudowanych feature’ów jak workspace’y, które służą do tworzenia monorepo. A Ruff z kolei jest linterem, który ma też wbudowane feature’y do formatowania kodu. Czyli linter to wyłapuje powiedzmy używając statycznej analizy kodu pewne pomyłki, albo na przykład zwraca uwagę, że ten kod jest niebezpieczny, bo coś tam. Więc to są narzędzia developerskie. I to, czym one się odróżniają, poza tym, że są napisane w Rust’cie, ale umówmy się, że bycie napisane w Rust’cie nie jest featurem.

Szymon Warda: Niemożliwe. Herezje.

Sebastian Buczyński Tak, to działały, działają zresztą dziesiątki razy szybciej niż jakby istniejąca konkurencja. Trochę to wynika z dwóch rzeczy. Po pierwsze dlatego, że jednak narzędzia, które były napisane w Pythonie są wolne, również mają swój jakby narzut historyczny. Tutaj po pierwsze zaczynaliśmy jakby ze świeżą kartą oraz używając języka, który na dzień dobry daje taki dobry baseline wydajnościowy. Natomiast napisanie managera pakietów to też jest, tak naprawdę temat mógłby być na zupełnie osobny podcast, ale nie sądzę, żeby to wiele osób interesowało już dzisiaj, bo też to były lata w ewolucji w Pythonie, nieudanych prób i stworzenia narzędzia, które ogarniałoby wiele edge case’ów. Między innymi dlatego, że jakby jednym z takich sposobów tworzenia paczek w Pythonie było to, że częścią był skrypt, więc mogło się tam dziać właściwie wszystko. A teraz jednak jest taka powiedzmy konwergencja ku temu, żeby te przypadki były proste, żebyśmy mieli faktycznie instalowalne paczki i żeby to działało jakoś tam sensownie i tak dalej. Wracając do wydajności. Developer experience ma dużą różnicę, czy się czeka na wynik lintera czy później typecheckera, bo Astral wydał też niedawno typecheckera, który nazywa się TY. Tak że i ten obszar gdzieś tam atakują, choć mają tu silną konkurencję. Ale z punktu widzenia developera, z punktu widzenia developer experience, jak robię jakieś zmiany w kodzie i chciałbym sformatować go albo przeszukać pod względem jakichś podatności czy zwykłych pomyłek typu nieużywana zmienna, literówka i tak dalej, i tak dalej, to ma dla mnie znaczenie, czy to się dzieje prawie natychmiast, czy mój mózg wybiera się na wyprawę, bo to trwa kilkadziesiąt sekund. I ten experience to jest to, co programistom Pythona dały te narzędzia. O ile instalowanie paczek, to ja do dzisiaj uważam, że nie robi mi różnicy, czy ta paczka się będzie, nie wiem, to drzewo zależności rozwiązuje 3 sekundy czy 30, bo ja to robię tam raz na jakiś czas, albo to się robi raz na jakiś czas. To o tyle taka codzienna praca, że po każdej zmianie faktycznie jest ten reformat, czy sprawdzenie kodu, to to już ma duże znaczenie. Więc zdobywają szturmem i to też jest moja obserwacja, również to widać po konferencjach, też po firmach, praktycznie większość ludzi o tym słyszało albo używa. To jest po prostu mega przydatne i działa dużo szybciej, co jest dużo przyjemniejsze.

Łukasz Kałużny: Okej, a patrząc się, dwa takie pytania. Czy uważasz, że to jest teraz, na przykład jak robimy nowy projekt, czy to powinien być po prostu standard, że używamy UV i Ruffa i trzeciego, zapomniałem, tego nowego? Nie przyzwyczaiłem się jeszcze…

Sebastian Buczyński TY.

Łukasz Kałużny: Do nazwy. TY, tak. Czy uważasz, że one powinny być po prostu defaultem w nowym projekcie, jak zaczynamy pracę nad czymś nowym?

Sebastian Buczyński Tak, zdecydowanie tak uważam, że to jest moja rekomendacja już od nawet od dwóch lat bodajże. Mówię o ile UV to jeszcze miałem mieszane uczucia, to Ruff jest takim moim zdaniem już standardem.

Łukasz Kałużny: Must have, must have po prostu. Pojawiło się, wiesz co, bo gdzieś tam pojawiły się jakieś też tak naprawdę gdzieś na przykład na Hacker Newsach inne rzeczy były trochę, krytyki wobec Astrala, że firma, która tak naprawdę jest sponsorowana z kasy VC, o tak, co niesie za sobą próby mocnej komercjalizacji w pewnym momencie. Czy gdzieś to teraz jeszcze się podnosi? Widać z tym jakieś związane problemy? Czy jednak działają w duchu tego community całego?

Sebastian Buczyński Ja myślę, że się podnosi. To też jest jakiś, nie wiem, część, nie wiem, zarządzania ryzykiem projektowym, bo tak jak wspomniałeś, rzeczywiście Astral jest firmą, która stoi za tymi narzędziami, jest wspierana przez VC. Wiemy, jak to VC, w którymś momencie będą chciały wyciągnąć zwrot ze swojej inwestycji. Te obawy trochę maleją. Moim zdaniem to jest trochę podobna sytuacja do czasów, kiedy ludzie się wzbraniali przed używaniem Reacta, bo Meta bodajże miała jakąś tam licencję, która była jakaś niesympatyczna i część osób patrzyła na to z dużą dozą ostrożności. Natomiast na razie to już jest mniej podnoszone, bo wszyscy się w tych narzędziach zakochali. Natomiast jak ostatni raz to sprawdzałem, to filozofią Astrala nie miało być, w którymś momencie komercjalizacja tych narzędzi. Zresztą one od początku miały jakieś całkiem przyjazne licencje. Ale za to parę miesięcy temu, bo w sierpniu 2025 roku, wydali swoje pierwsze komercyjne narzędzie, które nie jest już toolem takim typowym dla developera do instalacji w środowisku i tak dalej, tylko jest to prywatny rejestr pakietów, który dokłada parę dodatkowych rzeczy i na przykład wzbogaca UV. Z oficjalnego ogłoszenia wynika, że na przykład niektóre problemy, których nie są w stanie rozwiązać managerem pakietów, są w stanie rozwiązać właśnie taką synergią tego managera pakietów ze swoim prywatnym repozytorium, które jest oczywiście usługą hostowaną z tego co kojarzę i do zastosowania enterpriseowego, więc…

Szymon Warda: Dobra, a teraz trochę zejdźmy z innego, bo Python w sumie stał się takim trochę jak JavaScript właściwie. Można go spotkać niemalże wszędzie, dlatego, że w sumie jest dobrym klejem, tych bibliotek jest dużo i umie się przepinać między wieloma rzeczami. Jak to w ogóle wpłynęło na cały ekosystem pythonowy, na społeczność, że właściwie Python jest w Excelu, Python jest praktycznie wszędzie? A jeszcze teraz już temat kolejny będzie razem z AI-em, to AI bardzo Pythona lubi generować powiedzmy sobie. Co się w ogóle wydarzyło od tego czasu tak naprawdę?

Sebastian Buczyński Znaczy z mojej perspektywy to jest trochę fragmentacja społeczności, o której już wspomniałem. Ale z drugiej strony też dużo ludzi do tego języka wchodzi. Natomiast czy oni sobie zdają sprawę może z tego, że są programistami, bo piszą kod, albo ten kod im się generuje, to nie jestem przekonany. Czy to wpłynęło jakoś bardzo? Nie do końca bym powiedział, bo jednak dla mnie punktem odniesienia jest ten referencyjny interpreter CPython. I dopóki to nie wpływa na rdzeń, to uważam, że to może fajnie, że się pojawia. Ale czy to coś zmienia? Czy ci ludzie potem, nie wiem, interesują się programowaniem bardziej? Nie do końca. Ale mimo wszystko jest to ciekawe zjawisko, że Python staje się takim zdemokratyzowanym, powszechnie dostępnym narzędziem, z którym rzeczywiście można łatwo zacząć. Ale nie widzę na razie jakiegoś tam wpływu.

Szymon Warda: Załóżmy ryzyka, które ja widuję przy takich sytuacjach, to jest to, że nagle Python obrośnie, pythonowa technologia po prostu obrośnie dużą liczbą małych feature’ów potrzebnych w bardzo skrajnych i różnych zastosowaniach. To jest takie pilnowanie tego, żebyśmy mieli, trzymali ten core tak naprawdę, a nie dodawali po prostu rzeczy, o których też w sumie wspominałeś właściwie, że się pojawiają, załóżmy funkcjonalności, które powstają dla bardzo wąskiego zastosowania i tam są bardzo użyteczne. I czy jest sens się ich uczyć? Czy może nie, no nie? Czy tą fragmentaryzację widać? Czy tak na razie się bronicie jako społeczność przed tym i jest to dobrze zarządzane?

Sebastian Buczyński Z tego co widzę, bo znowu się odnoszę do tego referencyjnego interpretera, to nie ma za bardzo takich ruchów. Trzy takie dominujące nurty w rozwijaniu Pythona to po pierwsze są, cały czas są rzeczy dokładane do asyncio, jakichś tam dodatkowych rzeczy, czasem się ta czwarta rzecz. Pojawiają się jakieś drobne feature’y w języku, ale one nie są związane z fragmentacją uruchamiania w innych środowiskach przez innych ludzi, do innych zastosowań absolutnie. Mamy dorzucane rzeczy do typów i mamy rzeczy związane z wydajnością. To są takie cztery jakby główne. Jeśli chodzi o takie niszowe zastosowania, na przykład znowu było kilka prób, ja tego ogólnie nie śledzę, ale wiem, że jest też opcja uruchamiania Pythona na jakichś mikrokontrolerach. Tylko z tego, co wiem, to jest osobny interpreter, bo wiadomo, ten pełnowymiarowy by tam dawał za duży narzut. Więc na razie z tego co ja obserwuję, to jest, się dobrze bronimy i nie ma jakby, nie wiem, nie pojawiły się w bibliotece standardowej, z tego co wiem, żadne feature’y dedykowane pod Excela.

Szymon Warda: Jasne. A jak ma się właśnie ten wpływ, napływ ludzi z AI-a i w ogóle jak się na to zapatrujesz, właśnie na to, że to jest kod, który jest chętnie generowany przez LLM-y? Czy bardzo mocno używacie i jak to w ogóle wpływa na codzienną pracę w Pythonie?

Sebastian Buczyński Myślę, że wpływa podobnie jak w innych językach. Przy czym umówmy się, że kod, właśnie, ze względu też na to, że ten język postępował i ewolucja jego była dość intensywna w ostatnich latach, szczególnie w obszarze typingu i tego, że ten typing nie jest obowiązkowy, nadal interpreter działa bez wykorzystania informacji o tym, o adnotacjach typów. To też ten kod generowany przez LLM-y, ja bym powiedział, że nie jest production ready bez dodatkowych instrukcji. Nie jest production ready i nie przestrzega, powiedzmy nie wykorzystuje 80, 90% nawet tego co jest, tylko dalej lubi sobie na przykład wygenerować nieotypowany słownik jako strukturę danych. I potem się albo z tym człowieku bujaj, albo sobie to poprawiaj, czy coś z tym rób. Więc ja mam akurat taki nawet przykład z własnego podwórka, bo przyszedł do mnie szwagier właśnie z kodem wygenerowanym w ChatGPT i przez parę innych asystentów. On jest kierownikiem powiedzmy sklepu z elektroniką i chciał jakiś program do układania zmian i tak dalej, i tak dalej. I umówmy się, kod archaiczny, dosyć poklejone Qt, sam wrapper na Qt z paroma innymi rzeczami i jakoś to działało. Ale myślę, że to jest wyzwanie ogólnie dla Pythona, nadchodzące lata ze względu na to, że jest dużo sposobów, odnosząc się do tego, co Łukasz powiedział wcześniej, Zen of Python, one obvious way to do things i tak dalej. To widać tutaj, że jak generuję ten kod, to on jest wygenerowany taką zlepą tego, styli i różnych sposobów, jak się w Pythonie pisało przez kilka lat i pewnie nadal się pisze w różnych mniejszych, jak się mówi informacyjnych tam, Information Bubbles, ale jest to takie dość, powiedziałbym, mało stabilne. Trzeba by tak naprawdę takiego projektu z LLM-em w Pythonie właśnie usiąść i mu wyznaczyć dużo tych takich bazowych punktów typu właśnie adnotacje typów, lintery i tak dalej.

Łukasz Kałużny: Właśnie dostaliśmy, takie było jedno z pytań, oryginalnie tutaj Stick u nas na Discordzie jak to napisał: gang skrypciaków versus Python Whispers. Jak ogarnąć pythonowy AI slop wylewający się zewsząd? To było oryginalne pytanie. I tutaj dorzucając dalej, jak właśnie podejść do narzędzi, guardlace’ów? Bo też tam patrzyłem, że raczej chyba jak wszyscy skręciłeś też mocno w to, jak patrząc się tam, przeglądając Twoje aktywności i inne rzeczy, że chyba skręciłeś trochę też w Spec Driven Development, AI Assistant Development, w researche i trochę szkolenie z tego. I jak Ty na to teraz patrzysz? Jeżeli popatrzymy sobie, jak patrzysz właśnie na generowanie tego kodu pythonowego AI-em, ale już w profesjonalnych zastosowaniach komercyjnych?

Sebastian Buczyński Patrzę na to w taki sposób, że jeśli ktoś nie odrobił jeszcze, powiedzmy, pracy domowej w ogóle z takiego bootstrapowania projektu czy w ogóle budowania safety netu w postaci testów na odpowiednim poziomie i właśnie type checkerów i tak dalej, to w przypadku Pythona powoduje to tylko coraz większe jakby problemy i wyzwania. Ale nie jest to, powiedziałbym, rzecz stricte jakby pythonowa, tylko pewnie jest to szerszy problem, aczkolwiek jest to już teraz domysł. Więc ten AI Assistant, znaczy dla mnie to jest bardzo rzecz rozwojowa. Ja staram się nie formułować jakichś mocnych opinii teraz. Na pewno jest to amplifikuje. Wszystko to, co było złe, jest dużo gorsze. Rzeczy, które są łatwe, dobre do zrobienia, to w miarę to jakoś to całkiem nieźle to działa. Ale bez odrobienia takiej pracy domowej, to moim zdaniem to jest… To nie jest problem jakby stricte Pythona, tylko to jest problem ustawienia sobie flow jeszcze zanim się zacznie zapuszczać agentów i generować tony kodu.

Łukasz Kałużny: Dobra, a słuchaj, jak mówisz o tym flow czy w Twoim… Bo z ciekawości może pierwsze pytanie zanim pójdziemy co, żeby nałożyć kontekst. Claude Code, Codex, Cursor, masz jakieś swoje, Copilot, masz jakieś swoje preferencje co do narzędzi?

Sebastian Buczyński Ja jestem zagorzałym użytkownikiem Claude’a.

Szymon Warda: Witamy.

Łukasz Kałużny: Dobrze, będzie monotematycznie. Dobra, to zadam pytanie. Czy masz jakieś w swoim setupie, jesteś minimalistą, czy jednak może trochę hooków, innych rzeczy, jak taki Twój setup, na którym Ty lubisz pracować, bo każdy ma swój workflow w tym momencie, więc pytanie: jak Twój workflow przy projektach pythonowych, czy dodajesz właśnie jakieś hooki, toole specjalnie pod to czy lecisz bardziej na gołym setupie? Jaka jest Twoja preferencja osobista?

Sebastian Buczyński Setup jest w dużej mierze goły. Trochę może to jest błąd, niechęć do eksperymentów albo tego, że na tyle miałem ten flow ogarnięty przed wejściem tych asystentów, czy AI Assistant Coding, że wiele rzeczy po prostu mi zostało. Czyli są oczywiście narzędzia jak linter, jak formater, jak typechecker, tylko że dalej preferuję je odpalać ręcznie po zmianach, bo nawet jeśli robi to ten Claude, to ja widzę, że tam jest lag kilkusekundowy na samym uruchomieniu narzędzia, czego nie rozumiem do dzisiaj, ale jakby mniejsza o to. Jeśli chodzi o sam coding, no to bardziej skille myślę, to jest rzecz gorąca, ale też czegoś czego używam. Tworzę też jakieś swoje proste skille i wokół tego. Raczej setup jest jest goły, bym powiedział.

Łukasz Kałużny: Dobra. Z ciekawości, jaki taki skill masz, z którego najczęściej korzystasz pewnie, do czego służy? Jeżeli byś tak rzucił odruchowo pierwszy taki, który Ci przychodzi na myśl.

Sebastian Buczyński Pierwszy, który mi przychodzi na myśl, nie mogę powiedzieć, bo to jest związane z firmą, w której pracuję i wolałbym tego jakby nie nie wspominać. Więc przekornie powiem, że najczęściej używam claude’wego skilla do tworzenia skilli. Zarówno jako referencji jak i odpalania.

Łukasz Kałużny: Okej, okej, spoko. Raczej nie wiem jak Ty Szymon, ale ja też mam, mimo chęci do eksperymentowania, dochodzę do tego samego, że mam bardzo goły setup u mnie.

Szymon Warda: Playwright, parę (…) MCP i lecimy można powiedzieć. I dobry allow na bashu. To jest, wystarczy w dużym sensie. A taki jeszcze jeden sens, trochę pytanie dla dinozaurów można powiedzieć i ludzi, którzy nie siedzą w Pythonie. Jak sporo developerów i tu (…) web developerka, developerka, takie typowe aplikacje, forum, sklepy internetowe, ta grupa prawda, to jak słyszy Python, myśli Django. Jak to w ogóle wygląda? Bo pojawiło się Fast API, więc Django, nie Django. Jak ten ekosystem w ogóle wygląda, tworzenie już nie agentów, nie ML-a, nie wszystkiego innego, tylko web developerka?

Sebastian Buczyński Więc tu znowu jest kilka światów, bo Django żyje i moim zdaniem ma się dobrze i to źle, ale trudno. Znaczy źle dlaczego? Już mówię, nie ze złośliwości. Chociaż zdarzały mi się prezentacje, podczas których po wymówieniu słowa Django udawałem, że pluję przez ramię, to był to tylko żart. Tak że, powiedzmy tak, ja Django lubię, szanuję może bardziej, bo proste rzeczy robi się prosto. Natomiast to nie jest framework, którego moim zdaniem nie należy porównywać ekosystemowo do Fast API na przykład. Bo jednak Django dużo nudnych rzeczy takich boilerplate’owych załatwia. Czyli zarządzanie konfiguracją, tam jest sposób na zrobienie tego, zarządzanie migracjami, bazą danych jest wbudowane i tak dalej, i tak dalej. Jak to jest zrobione, to już jest inny temat. Ale generalnie jest po prostu. Bierze się Django i można wiele rzeczy zrobić. Plus Django Rest Framework, znowu jeszcze bardziej jaskrawe niż samo Django. Żyje, ma się dobrze, to niedobrze, że tak jest. Dlaczego? O ile samo Django, jakby tu jeszcze mam uczucia ciepłe, to do DRF-a mam uczucia dużo gorsze, dlatego, że on nie nadążył za zmianami w języku, jeśli chodzi chociażby o adnotacje typów. Więc mamy dołożone rzeczy, które są typowo pod niezawodność oprogramowania czy w ogóle używanie typów, które pewne rodzaje błędów nam załatwiają. To DRF jest biegunowo niekompatybilne, bo nie robi z tego użytku i większość tych rzeczy idzie po prostu do kosza. Kontr przykład. Bo znowu to jest dygresja trochę. Mamy największy, najsłynniejszy ORM SQL Alchemy, w którym generalnie można zrobić wszystko. I w związku z tą rewolucją typową powstało nowe API, które dało się typami w ogóle opisać. Tak że został przeprojektowany całkowicie ten interfejs, ale w dobrym celu po to, żeby można było po prostu wykorzystywać nowe moce języka. Ale jeśli chodzi o te frameworki, to dla mnie to są znowu, to są trochę lekko dwa światy, bo z jednej strony mamy Django, którym nawet z średnich zespołów można wyciągnąć coś, bo to są proste klocki, z których budujemy aplikacje i to działa i nie musimy się zastanawiać za każdym nowym projektem, jak konfigurację zorganizować. Versus mamy na przykład powiedzmy Fast API czy inne micro frameworki, które wymagają od nas właśnie tej zabawy w klocki. Albo jeśli to jest większa firma, albo kolejny mikroserwis w tym samym zespole, coś takiego, to sobie po prostu skopiujemy te swoje nawyki i tak dalej, te swoje narzędzia. Ale jak startujemy, to nie mamy dosłownie nic bardzie. Nadal trzeba sobie wymyślić w jaki sposób zorganizować niektóre rzeczy, czy użyć dependency injection, czy nie użyć, w jaki sposób te konfiguracje ładować i tak dalej, i tak dalej. I to jest taki znowu boilerplate, który się robi. Więc ja bym tego nie porównywał bezpośrednio. Chociaż tak, w web developmencie, właśnie, djangowcy, ludzie, którzy lubią składać z klocków, czyli potrzebują większej kontroli, to Fast API, Flask i inne frameworki. Plus mamy jeszcze niepokornych, trendujące jakieś frameworki, które próbują Django zastąpić, a jednocześnie nie być, powiedzmy być trochę bardziej nowoczesnymi, jak Starlight. Ale to są wszystkie niszówki. To naprawdę słyszę o tym od czasu do czasu, ale żeby ktoś tego faktycznie używał, to jest to na pewno jakaś mniejszość.

Szymon Warda: Jasne.

Łukasz Kałużny: To ja sobie przejdę do tego, co powiedziałeś, że może być z tego oddzielny odcinek. Słuchaj, bo sześć lat temu napisałeś tą książkę na temat Implementing The Clean Architecture. I mam takie rzeczy, które mi się tutaj, bo w pierwszym rzuciłeś taką rzecz nawet na początku, którą już trochę ustawiłeś tą rozmową, że da się to robić na samym początku, że da się to robić Python way, a nie Java way w Pythonie, jeżeli chodzi o clean architecture. I takie pytanie, 2 zasadnicze do dyskusji. Czy tak naprawdę nadal implementujesz w takim rozumieniu jak patrzyłeś na to samo, jak patrzyłeś na to sześć lat temu, te clean architecture, jak to oglądaliśmy? Bo zresztą kojarzysz, jest dużo ruchów anty clean architecture, jak sobie popatrzymy i podejść. A druga rzecz, co od tamtego czasu tak naprawdę w Pythonie się zmieniło? Bo mi przychodzi na myśl właśnie Fast API, które wymieniliśmy, zmiany w SQL Alchemy, Pydantic, który też stał się w sumie chyba standardem, tak patrzę z mojej perspektywy, w budowie API, backendów, właśnie ten Pydantic v2. I jak to się między Tobą tak naprawdę tutaj, tym wszystkim, to wszystko klei? Jaka jest Twoja perspektywa po tych sześciu latach na to wszystko?

Sebastian Buczyński Tak, ja bym powiedział nawet po ośmiu latach, bo mniej więcej tak chyba pierwsze próby były. I na pewno przez te dwa lata pierwsze było bardzo dużo zmian. Zresztą jakby normalne, że na początku tych krzywa nauczania jest bardziej ostra. Ale skoro nawiązywałeś, tak, też w języku dużo się zmieniło, co ułatwiło wiele rzeczy i powiedzmy niektóre kwestie, właśnie jak ten wspomniany Pydantic, to jest dobry bardzo przykład, bo właśnie w 2018 roku robiąc prezentację jeszcze we Wrocławiu na temat czystej architektury, powiedziałem, że pewnie pojawi się jakaś biblioteka, która będzie robiła to i to i jeszcze będzie zgodniejsza z typami. To Pydantic. Później się o nim dowiedziałem, nie bezpośrednio po prezentacji, ale jakoś później. Więc dokładnie w tę stronę to idzie. To znaczy tak naprawdę otworzyłeś bardzo szeroki wątek i zastanawiam się, może się skupię najpierw na kwestiach pythonowych, dobra, bo chyba to będzie najłatwiejsze z tego, o czym rozmawialiśmy, a później możemy ogólnie o czystej architekturze jeszcze porozmawiać jako o podejściu. Więc o co chodzi z tym Java way versus Python way? Więc język, każdy język zresztą ma swoje jakieś idiomy. Choć moja osobista obserwacja, nie wiem, czy też się zgodzicie z tym, wydaje mi się, że też jest jakaś pewnego rodzaju konwergencja, że na przykład te elementy języków funkcyjnych też wchodzą do języków jakichś bardziej ogólnego zastosowania.

Łukasz Kałużny: Raczej…

Szymon Warda: Bardzo mocno.

Łukasz Kałużny: Raczej ogólnie mamy cichy powrót programowania funkcyjnego, nie mówiąc, że to funkcyjne. Jeżeli tak, to moja taka obserwacja.

Szymon Warda: Elementów, powiedzmy sobie.

Łukasz Kałużny: Elementów, tak, elementów.

Sebastian Buczyński Tak, ale elementy są. Więc w każdym razie każdy język to przynajmniej wcześniej to było dużo bardziej widać, ale miał wiele swoich idiomów. I teraz, jak spojrzy się na na przykład na programistę Javy, który na co dzień programuję w Javie, ale próbuję coś skrobnąć w Pythonie i widać przez ramię, że to nie jest pythonowy kod, tylko ktoś pisze Javę w składni Pythona. I teraz jak się weźmie na przykład jakiś wzorzec powiedzmy, typu czysta architektura, to jest fajny przykład, bo jest skomplikowany, więc łatwo uderzać w kilka słabych punktów, bo wiadomo, że tam boli, bo niektóre rzeczy na pewno są kwestionowalne, to na przykład, może jeszcze nie w samej czystej architekturze, ale w portach i adapterach jest coś takiego, że mamy ten adapter wejściowy czy driven adapter, który składa się z jakiejś klasy konkretnej, jakiegoś interfejsu. I załóżmy, że zarówno ten interfejs, jaki ta klasa konkretna należą do tego samego, powiedzmy, komponentu czy powiedzieliśmy modułu może, koncepcyjnie jakiegoś bounded contextu, whatever. I pytanie, po co nam ten interfejs, jak jest klasa już konkretna, która też ma swój interfejs, bo też ma jakieś metody? I to jest rzecz, której, bo jeszcze w Pythonie na przykład nie ma interfejsów, od tego zacznijmy. Jako building bloków w ogóle nie ma. Mamy klasy abstrakcyjne, które co ciekawe nie są jakby składnią języka, tylko są zaimplementowane w języku. Więc taka niechęć do używania czy nieumiejętność się łączy po prostu z brakiem jakby tooli w danym narzędziu. Więc od tego zacznijmy w ogóle. Później z typowaniem przyszły inne narzędzia, ale to już znowu była dygresja do dygresji. I taki bardziej jaskrawy przykład, w Javie podstawowym building blokiem są klasy, piszemy klasy, piszemy klasy, nie zastanawiamy się nad tym. W Pythonie nadal nawet silna jest dzisiaj grupa klasosceptyków. Oni będą pisać tylko funkcje, bo tak jest prościej i tak dalej, i tak dalej. Więc to jest mniej więcej taki punkt wyjściowy, od którego można można zacząć. Jeśli chodzi o same jeszcze zmiany, już tak krótko, w samym języku przez te ostatnie lata, to po pierwsze, właśnie eksplozja typowania nie tylko samej składni do adnotacji typów, ale też ekosystemu narzędzi wokół tego, który narósł, dojrzałości społeczności używania tych narzędzi i coś, co mi się podoba, ale podoba mi się trend, nie podoba mi się kierunek do końca, contener dependency injection. Bo taki problem tego typu zarządzania zależnościami on istnieje niezależnie powiedzmy od tam, jeśli tylko projekt jest wystarczająco wyrafinowany. On istnieje, tylko rozwiązujemy to w jakiś inny sposób. Ale teraz wprowadzanie takich first class citizens, wprost contenerów dependency injection do języka też moim zdaniem jest fajnym kierunkiem, który ułatwia implementację wielu, wielu wzorców. Więc tak z punktu widzenia języka, to myślę, że te 3 punkty.

Łukasz Kałużny: Okej, czyli języka. A jeżeli teraz pójdziemy, bo tak, powiedziałeś właśnie o paru takich rzeczach, właśnie tych klasosceptykach, tych wszystkich podejściach, które są w Pythonie. I zastanawiając się troszeczkę głośno, bo u Ciebie nawet, właśnie nie pamiętam, w którymś miejscu padło, że clean architecture is not a silver bullet, Takie bardzo standardowe. To jeżeli w ogóle na to patrzysz, to kiedy w ogóle zastanawiać się nad komplikowaniem tego kodu, to nazwijmy i projektowaniem, kiedy z tego tak naprawdę jest wartość, o tak, Twoim zdaniem, w przypadku Pythona i implementacji tego wzorca? W szczególności, że też Python dość mocno, on pod spodem po cichu to też moim zdaniem miał od dawna, o tak, że vertical slice’y też tam już istniały od dawna, tylko nie były tak nazywane, patrząc się na to, jak kod jest pisany.

Sebastian Buczyński Okej, to od końca zacznę, może od tych vertical slice’ów. Trzeba powiedzieć, że na przykład w Django, jak pojedynczy taki, nie wiem, repozytorium powiedzmy z projektem Django nazywamy projektem i w ramach jednego projektu możemy mieć kilka aplikacji. I one mogłyby, gdyby ludzie ich tak wykorzystywali oczywiście, realizować właśnie koncepcję vertical slice’ów, bo one mają osobne modele bazodanowe, osobne migracje i tak dalej, i tak dalej. W praktyce guzik z tego wychodzi, bo na przykład tworzy się jedną aplikację typu core, z której wszyscy biorą ile chcą, importują i wiadomo, że to nie realizuje. Ale to jest coś innego, to jest infrastruktura do realizacji tego wzorca. Tak więc on rzeczywiście istniał, nie był do końca tak pisany. Jeśli chodzi o główną część Twojego pytania, czyli ten silver bullet, to wiesz co? Właśnie tutaj trochę też obserwacja z perspektywy architekta różnych zespołów, ale też z team leadera, który zmieniał pracę 2 albo 3 razy i musiał od nowa uczyć ludzi albo pokazywać, to z jednej strony to podejście się upraszczało, ale z drugiej strony też pokazało mi bardzo ciekawą rzecz. I to nie jest absolutnie techniczna sprawa, tylko to jest tak naprawdę, powiedziałbym, jakaś społeczna, jakaś liderska i tak dalej, że załóżmy, że mamy podejście w stylu czysta architektura albo coś prostszego, nie wiem, jakieś tam powiedzmy standardowe idiomy w Django wykorzystujemy, cokolwiek. I teraz, jeżeli ja mam zespół i mam projekt i więcej wysiłku kosztuje nauczenie ludzi, że tę część robimy prosto, a tę część robimy w jakiś bardziej wyrafinowany sposób, bo się gubią. Znaczy trudniej jest ich tego nauczyć po prostu. Pewnie by się w skończonym czasie nauczyli, ale jest to dużo większe wyzwanie. I potem też dbanie o spójność tego projektu. Mi się zmieniło na tyle, że jakbyś miał podejście proste i podejście wyrafinowane, to ja bardziej szukałem czegoś tak, wiecie, zbliżonego już bardziej przez upraszczanie tego, powiedzmy, referencyjnego wzorca czystej architektury, usuwanie z niego elementów, które nie dają powiedzmy wartości.

Łukasz Kałużny: Raczej mówisz, ja dokładnie pamiętam, Szymon pamięta takiego ERP-a w firmie, w której wspólnie pracowaliśmy, który akurat był w .Necie napisany w clean architecture i wszystkich tych. Musiałem wejść, miałem takiego okropnego buga i stwierdziłem, że go, mam dostęp do kodu, mogę zrobić pull request, sam poprawię. I miałem taki moment osobiście, po czym ja zhejtowałem clean architecture, jak musiałem sam dodać coś w istniejącym code base’ie, którego wiedziałem gdzie jest, co muszę dodać, ale żeby to dodać poprawnie, wiesz, taki onboarding, to była masakra, żeby dodać to poprawnie. I takie pytanie, bo mając jakąś swoją perspektywę na kompetencje pythonowe na rynku, te wyrafinowane wzorce, takie, które gdzieś tam pojawiają się właśnie, Java, .Net z nich żyją, tak, nie oszukując się z nazw tych, bo tam było tego najwięcej realnie, tego typu projektów…

Szymon Warda: Bo tam są (…), więc łatwo jest to zrobić, że tak powiem.

Łukasz Kałużny: Ale w tym, ale nie. I zmierzam do tego, że te clean architecture troszeczkę właśnie, jak jest z kompetencją na rynku rozumienia takich właśnie, nazwijmy to, zaawansowanych praktyk inżynierskich, o tak? Nie chcę tego używać tutaj, wrzucać clean architecture, ale nazwijmy sobie właśnie takich innych podejść niż budowanie tego prosto?

Sebastian Buczyński U ludzi, którzy… Znaczy mówię oczywiście tylko ze swoich obserwacji oczywiście, jest to wiadomo jakaś bańka, ale wydaje mi się, że dość szeroka. U ludzi, którzy przyszli z innych języków - spora. Ale oni przekomplikowują z kolei, wrzucają elementy, które nie mają wartości, ale po prostu tak się robiło i to przenoszą. U pythonowców czystej krwi nie ma znajomości wzorców jako takich, co nie znaczy, że ich nie używają. Bo oni ich używają tylko albo nie znają nazw, albo one są zrobione po ichniejszemu, po pythonowemu. Dam wam jeden przykład właśnie z dependency injection. Jak mamy kontener dependency injection, to explicite wprost deklarujemy rzecz taką jak zależność i jak ona jest rozwiązywana czasami, czasami to jest semi automatyczne i tak dalej i tak dalej. W Django podejście do dependency injection jest takie, że mam różne silniki cache’a, mogę mieć cache oparty o Redisa, mogę mieć cache oparty in memory, mogę nie mieć w ogóle cache’a, tylko będę udawał, że mam, ale będę to wiadomo, do dev/nulla wszystko wysyłał. Dependency injection jak w pysk strzelił. Otóż nie. W Django jest rozwiązane to w taki sposób, że jest konfiguracja, która mówi jakiej klasy używasz pod spodem, napisane w stringu oczywiście, bo przecież nie podany obiekt i jest taki proxy object, który można sobie zaimportować, używać w różnych kontekstach i pod warunkiem, że przeszło to przez konfigurację Django, to pod spodem będzie ta wybrana implementacja. Więc jest to wzorzec jakiś tam rozwiązywania. Jest zaimplementowany zgoła inaczej i to jeszcze w sposób nierozszerzalny, bo jak chcesz programisto zrobić sobie coś takiego w swoim Django, to bujaj się, framework Ci tego nie da. Natomiast wiele innych powiedzmy wzorców, ludzie czasami to wymyślają od nowa, ale jakoś tego używają. Albo ich narzędzia, właśnie, to jest też trochę fenomen, tylko ciężko będzie o konkretny przykład. Są narzędzia, które implementują jakieś wzorce ewidentnie, ja to znam, nie wiem, z konferencji sprzed lat, ale ani razu w dokumentacji ta nazwa wzorca nie pada, nie ma, nie istnieje.

Łukasz Kałużny: Kurde, ja pamiętam z tymi ze wszystkimi schedulerami, konsumerami chyba tak było, z schedulerami, że właśnie implementowały coś konkretnego. Wiem o czym mówisz, o tak, jak miałem okazję chwilę popracować w projektach pythonowych. To był też dla mnie taki osobisty szok. Dobra, będziemy chyba tutaj, słuchaj Sebastian, podsumowywać i kończyć. Jeżeli ktoś by miał teraz, bo… Inaczej, sam jestem tego, ja się śmieję, przez AI-a jestem tego w pewnym sensie trochę ofiarą. Jeżeli przychodząc z innego języka, jakie byś takie, jedną rzecz, którą uważasz, że warto byłoby poznać w Pythonie, skierować, poszerzyć swoją świadomość, jeżeli przechodzimy do Pythona z innego języka, co byś w tym momencie, jakąś taką jedną rzecz, którą chciałbyś na przykład, że taka osoba poznała?

Sebastian Buczyński Zdecydowanie skierowałbym osobę w stronę tego stosu narzędzi od Astrala. Z jednym wyjątkiem. Jeśli chodzi o typy, to teraz chyba najfajniejszą opcją na rynku jest Pyrefly, czyli takie narzędzie, jeśli dobrze pamiętam, znowu z Mety, które (…) adnotacji typów. Jeśli mówimy o takim webowym zastosowaniu typowo, tak, albo jakimś takim semiprojektowym, biznesowym. Bo jeżeli ktoś będzie przychodził do Pythona, żeby robić numeryczne operacje czy jakiś tam machine learning, to oni mają swoje narzędzia. W ogóle jest…

Łukasz Kałużny: Tak, ja tego wątku nawet, wiesz co, nie poruszałem, bo on jest tak szeroki. Niektórzy by się obrazili jakbyśmy powiedzieli prawdę, że tam pod spodem to tak naprawdę to są interfejsy tylko do C, C++.

Sebastian Buczyński Tak.

Łukasz Kałużny: Dobra, słuchaj, to słuchaj Sebastian, to dzięki za tą rozmowę dzisiaj, była ciekawa. W tym trochę potwierdziłeś moich też obserwacji, o tak, które tak oglądamy, że to jest, że Python ma ciekawy kierunek, o tak, w całości.

Sebastian Buczyński Tak, ale właśnie odnosząc się do kierunku, jeszcze jeden komentarz. Najnowsza moja informacja z ubiegłego roku pod koniec rozmowy na konferencji z jednym z core developerów, nie ma w Pythonie, powiedzmy, takiej wiecie, roadmapy wyznaczonej na 10 lat do przodu i tak dalej, gdzie ten język miałby być. Oczywiście kontynuujemy projekt Faster CPython i na pewno ewolucja systemu typowania, czy tam asyncio już teraz wolniej będą sobie postępować, ale tak to obecnie wygląda. Nawet jeśli Python się gdzieś tam, nie wiem, wbija na salony albo w jakichś szerszych zastosowaniach się pojawia, to jeszcze nie odbija się to w żaden sposób na samym języku. Plus sam język nie ma ambicji też, żeby nie wiem, być uruchamiany na lodówkach, może tak powiem.

Szymon Warda: Dobrze, to tyle w takim razie.

Łukasz Kałużny: Dzięki.

Szymon Warda: Dzięki.

Łukasz Kałużny: Trzymajcie się.

Sebastian Buczyński Dzięki.