Czy Python ma jakieś wady patrząc na Nim, Mojo, Bend?

Witam wszystkich, czy język Python ma jakieś wady zwłaszcza teraz gdy robią coś z jego wielowątkowością dzięki zastosowaniu kompilatora JiT w Pythonie 3.13?
Mamy już mnóstwo kompilowanych języków o składni przypominającej Pythona jak Idris i Scala 3 na JVM. Więc czy Python ma jakieś wady jako język skoro zdominował cały świat i nie zanosi się na to aby jego trend spadł na niższe miejsce. Ludzie na reddit narzekają że bardzo łatwo się go nauczyć i przez to powstaje bardzo słabej jakości kod źródłowy.
https://www.reddit.com/r/Python/comments/1en1rl2/what_are_the_real_downsides_of_python_and_can_you/

Idris i Scala 3 mają składnię przypominającą Pythona? Chyba nie.

Mi w Pythonie przeszkadza na co dzień (kontekst: devops, nie piszę kodu biznesowego, raczej skrypty infry):

• len(my_list) zamiast po ludzku my_list.length() i wiele tego typu "globalnych" funkcji które wedle OOP mogły by być metodami, EDIT: sorted(...) kolejny niesmak
• może jestem spaczony Javą, ale nie cierpię skrótowców typu format_exc czy functools albo iteritems, nie można po prostu napisać słowa po angielsku całego?
• dramatyczne zarządzanie zależnościami, mieszanie się pakietów systemowych (np. z apta) z tym co z pipa, czasem lepiej nawet nie używać bibliotek

sergioleone napisał(a):

Mamy już mnóstwo kompilowanych języków o składni przypominającej Pythona jak Idris i Scala 3 na JVM.

każdy język z https://en.wikipedia.org/wiki/Off-side_rule ma składnię przypominającą pythona? dobre sobie. sam pomysł sięga 1966 roku, a pierwsze publiczne wydanie pythona (wersja 0.9.0) to 1991 rok. zaginasz czasoprzestrzeń.

nawet https://en.wikipedia.org/wiki/ABC_(programming_language) pojawił się w 1987 roku i to on stanowił inspirację dla pytona, a nie odwrotnie:

ABC had a major influence on the design of the language Python, developed by Guido van Rossum, who formerly worked for several years on the ABC system in the mid-1980s.

@kelog

Mi w Pythonie przeszkadza na co dzień (kontekst: devops, nie piszę kodu biznesowego, raczej skrypty infry):

len(my_list) zamiast po ludzku my_list.length() i wiele tego typu "globalnych" funkcji które wedle OOP mogły by być metodami, EDIT: sorted(...) kolejny niesmak

To akurat pragmatyczny wybór, len, jako globalna funkcja jest szybsza. Co mi akurat w ogóle nie przeszkadza, a nawet jest czytelniejsze, bo wiem na pewno, że to długość.

Co do wad Pythona, to na pewno wydajność i zrównoleglanie "CPU bound", ale i to się zmienia; choć, znowu, mi zupełnie nie przeszkadza, akurat tam gdzie piszę jest to nie istotne, albo mogę użyć bibliotek, jak numpy, scipy, itd.

w Python importowanie ma spoko składnię

jest:
from “library” import [podpowiedzi IDE]

W js niestety jest ten szyk przestawiony i IDE już nie pomoże.

Z drugiej strony mnie osobiście przeszkadza brak klamry i stosowanie wcięć zamiast nich (jak w plikach yaml)

Mojo jest prawie identyczny co python, a ma tam trochę lepszą wydajność, ale też inne problemy.

Jak już by ktoś miał jakiś problem AI/Deep learning, to pierwsze co to chcesz zoptymalizować to horyzontalnie czy wertykalnie.
Też wtedy możesz się zastanowić czy może w C++ to zaimplementować, czy jakiś framework da ci duży boost typu jax, a może przejście na Mojo.

Przy skalowaniu to i tak masz zupełnie inne narzędzia, które też akurat nie wiem jak mojo wspiera typu GPIPE czy innych jak Ray.
Albo samemu możesz coś sobie zaprojektować przy użyciu jakiejś kafki, gdzie możesz zrobić pattern typu data pararellism, czy model parallelism poszczególne elementy rozrzucić po kilku kartach graficznych.
Przy uczeniu rozproszonym możemy synchronicznie czy asynchronicznie kumulować gradient i aktualizować nim na różnych jednostkach obliczeniowych ich parametry.

Taki pytorch pozwala pythona model skompilować do torchscript, który ma znacznie lepsze osiągi, bo wykonuje jita.

Mojo pozwala na spore optymalizacje, ale nie korzystałem podobno jak C++/Cuda osiągi podobne potrafi.

Choćby to:

Inne problemy to dynamiczne typowanie, słaby performance, dużo legacy, async io (jak już mam wolny język to chcę przynajmniej green thready), GIL, mnóstwo mechanizmów, których nikt nie używa a tylko szkodzą.

Generalnie Python to IMO całkiem słaby język. Jedyne co go ratuje to fakt, że był ostoją normalności w czasach Javy i można było w nim klepać proste skrypty/CLI bez tworzenia AbstractBeanFactory i użerania się mavenem. Sam często go używam do skryptów, bo mam w tym duża wprawę z uwagi na to, że robiłem tego dużo na studiach

Podsumowując: jak ma to być coś prostego i napisane w czymś co każdy umie to Python jest dobrym rozwiązaniem. W innych wypadkach wolę statyczne typowanie i język, gdzie trudniej o bugi a tooling jest lepszy

Nie wiem o co chodzi z tymi pakietami, bo ja path + requirements i venv i nie widzę problemu. Ale do rzeczy, co to za wada asynchroniczne IO i dynamiczne typowanie? LOL

A po cholere Ci dynamiczne typowanie jak mozesz miec statyczne typowanie z inferencja typow?

slsy napisał(a):

mnóstwo mechanizmów, których nikt nie używa a tylko szkodzą.

Jakie mechanizmy masz na myśli?

W innych wypadkach wolę statyczne typowanie i język, gdzie trudniej o bugi a tooling jest lepszy

Jakie języki masz na myśli?

stivens napisał(a):

A po cholere Ci dynamiczne typowanie jak mozesz miec statyczne typowanie z inferencja typow?

Oczywiście, że można mieć, (chociaż w Pythonie tego nie zrobią) pytałem w jaki sposób dynamiczne typowanie jest wadą.

Chociazby dlatego, ze podpowiadanie nie dziala, albo dziala czasami i gorzej niz jakbys mial pelnoprawny statyczny system. Refactorowanie to meka, a niektore klasy bledow widzisz dopiero w runtimie

EDIT: zaraz ktos przyjdzie i zacznie "argumentowac", ze "blablabla testy" - chodzi o to, ze jak napiszesz linijke, ktora nie ma zadnego sensu, to dostajesz natychmiastowy feedback, a nie dopiero kiedy odpalisz (o ile napiszesz) test

Nie odczuwam czegoś takiego, podstawą software engineering i tak są testy; nawet jak wziąścć pod uwagę powyższe, to i tak zalety dynamicznego zdecydowanie przewyższają wady, więcej patternów, czytelny kod, ekspresywność...

czytelny kod, ekspresywność

Przeciez mowilem juz o inferencji typow

więcej patternów

Anty-patternow chyba, vide duck-typing

Skoro język ma mniej ograniczeń, to ma więcej patternów, Peter Norvig o tym pisał. O jakich anty patternach piszesz? Może że ktoś pisze shit code, ale co tu ma dynamiczność/statyczność do rzeczy?

Skoro język ma mniej ograniczeń, to ma więcej patternów

To najwiecej patternow ma assembler XD A to, ze Python nie ma arytmetyki wskaznikowej - jak C - to tez jest minus a nie plus! (Sarkazm)

Absurdalna rozmowa.

Dynamiczne typowanie to iluzja "wolnosci", ktora pryska w runtimie

100%-owo działająca (bo dzięki statycznemu typowaniu) inferencja typów to też dodatkowe wzorce, np. implicity w scali (które de facto są całym osobnym światem, metaforycznie to taki język w języku). kompilator statycznie liczy typy i na ich podstawie wyszukuje i wstawia argumenty. w pytonie tego porządnie (albo wcale) nie zrobisz, bo brak statycznego typowania oznacza brak gwarancji poprawnego przeliczenia typu.

kacze typowanie w pytonie rozwala refaktor - przerabiałem ten temat w praktyce z użyciem intellija.

testami można kompensować częściowo brak statycznego typowania, ale jeszcze nie uświadczyłem testów automatycznych w pytonie. mamy naklepaną infrastrukturę w pytonie i każdy boi się to refaktorować, bo testów automatycznych w ogóle nie ma. taka jest smutna rzeczywistość. można być don kichotem i próbować to naprawiać, ale de facto kod w pytonie to kod do, którego się wrzuca śmieci. zamiast testów i refaktorów jest copy + paste + małe niekompatybilne zmiany (gdyby były kompatybilne to nie byłoby potrzeby robić copy + paste). oczywiście powodem tak słabej jakości kodu pytonowego jest to, że ogólnie nie jesteśmy pytonowcami, więc w sumie nie jest to reprezentatwyny przypadek w kontekście chęci zostania stricte pytonowcem.

ogólnie smutna rzeczywistość jest taka, że 90%+ kodu pisanego komercyjnie ma słabą jakość i względnie słabe pokrycie testami. masówka wymaga języka, który wspomaga odgruzowywanie słabego kodu. pyton tego nie wspomaga, bo braki w testach i jakości kodu rozwalają możliwość refaktoru i efektywnego ogarnięcia bajzlu.

lion137 napisał(a):

co to za wada asynchroniczne IO

@lion137

Async IO jest trudniejsze do użycia niż tradycyjne IO. Dwa różne sposoby na zrobienie tego samego to też wada. Async IO ma sens w językach, gdzie dbamy o wydajność (Rust) albo tam, gdzie dodano je po czasie (C#, Python). Piszę to dlatego, że Python często jest przedstawiany jako "święty grall programowania", gdzie może wydajność jest słaba, ale nigdzie indziej nie pisze się szybciej i ładniej. W przypadku IO green thready są po prostu prostsze i bardziej eleganckie w użyciu. Analogicznie języki z GC są prostsze w utrzymaniu i nie wymagają tyle mechanizmów co ręczna alokacja pamięci.

dynamiczne typowanie

Wady są większe od zalet. Nie byłaby to wada, gdy doświadczenie w pisaniu kodu było takie samo jak w statycznych językach, ale za każdym razem jak wracam do Pythona okazuje się, że jednak tak nie jest

Jakie mechanizmy masz na myśli?

@anonimowy dynamiczne ficzery jak nadpisywanie propertiesów, monkey patching itd. Normalnie się tego nie używa, ale trzeba mieć to z tyłu głowy

Jakie języki masz na myśli?

Rust i Go są całkiem czytelne i dobrze zaprojektowane. W obu przypadkach tooling po prostu działa bez żadnego kombinowania

@stivens

Dynamiczne typowanie to iluzja "wolnosci", ktora pryska w runtimie

Jaka iluzja, jak pryska

@slsy

@lion137

Async IO jest trudniejsze do użycia niż tradycyjne IO. Dwa różne sposoby na zrobienie tego samego to też wada. Async IO ma sens w językach, gdzie dbamy o wydajność (Rust) albo tam, gdzie dodano je po czasie (C#, Python). Piszę to dlatego, że Python często jest przedstawiany jako "święty grall programowania", gdzie może wydajność jest słaba, ale nigdzie indziej nie pisze się szybciej i ładniej. W przypadku IO green thready są po prostu prostsze i bardziej eleganckie w użyciu. Analogicznie języki z GC są prostsze w utrzymaniu i nie wymagają tyle mechanizmów co ręczna alokacja pamięci.

OK Async IO ma learning curve, alew sumie jest prostsze, bo jest na jednym watku

Wady są większe od zalet. Nie byłaby to wada, gdy doświadczenie w pisaniu kodu było takie samo jak w statycznych językach, ale za każdym razem jak wracam do Pythona okazuje się, że jednak tak nie jest

Trochę niezrozumiale, co to za wady większe od zalet?

Trochę niezrozumiale, co to za wady większe od zalet?

Co to za zalety wieksze od wad?

Wadą Pythona jest głównie to, że istnieje

lion137 napisał(a):

Trochę niezrozumiale, co to za wady większe od zalet?

@lion137 brak pewności, że typy są na pewno sprawdzane. Biblioteki open source/legacy kod nie koniecznie mają typy. Indeksowanie IDE też działa średnio w porównaniu do statycznych języków

Są narzędzia zastępcze jak pydantic do validacji i mypy do statycznej analizy typów, a do zależności pakietów poetry.

Wiadomo, kompilowany język jest lepszy, ale skryptowe są całkiem przydatne.
Backend do pythona w C++ idzie prosto napisać, można wystawić jakiś interface do sterowania i ludzie mogą sobie moddować, pisać swoje pluginy, które będą jakimiś np. filtrami przy innych operacjach uwzględniane.

Sam blender też udostępnia pythona jako język skryptowania i sam kiedyś użyłem tego żeby model CAD wyświetlić, dodać bones i automatycznie uruchamiać sekwencje ruchów, czy nawet pobierać jeśli ktoś manualnie poruszał modelami, pobierać wszystkie informacje i potem np. gdzieś wysyłać do modułu sterującemu i odzwierciedlać ruchy na ekranie dość banalnie.
Ręcznie idzie zrobić praktycznie wszystko, ale można jakieś żmudne czy trudne zadania łatwo zautomatyzować.

Wiele dystrybucji linuxa czy chrome, ma pełno narzędzi pomocnicznych napisanych w pythonie.

Tak jeśli się zrobi w deep learningu jakiś graf matematyczny obliczeń to łatwo go zjitować na dowolny procesor CPU,GPU,TPU, czy nawet Kwantowy komputer.
Wszystkie ciężkie i skomplikowane technicznie elementy są stworzone w backendzie np. C/C++/Rust, a do pythona dodaje się binda.

Ja tam traktuje pythona jak kalkulator, coś takiego jak chcę na szybko policzyć coś to, raczej wybieram interactive pythona niż otwieram kalkulator, bo jak się okaże, że trzeba zwizualizowć.

A tak pośrednio to najlepiej Jave wybrać, bo C++ za dużo męczarni, Python za wolny jak wszystko leci w maszynie wirtualnej i tak są różne przyspieszające odnogi pythona typu pypy.
W javie można też od razu na androida fajnie pisać jak ktoś lubi i jest możliwość łatwego łączenia z C++, debugować też idzie na poziomie javy i opcodów.

dependency management

slsy napisał(a):

lion137 napisał(a):

Trochę niezrozumiale, co to za wady większe od zalet?

@lion137 brak pewności, że typy są na pewno sprawdzane. Biblioteki open source/legacy kod nie koniecznie mają typy. Indeksowanie IDE też działa średnio w porównaniu do statycznych języków

True, nadziałem się, ale i tak dla mnie ta drobnostka (tylko do kodu bez hintów, do backendu zawsze sobie dodaję, do data science tylko do public API) nie przesłania zalet dynamic typing.

Ale wciaz nie podales zadnych zalet.

Padlo tylko czytelny kod, ekspresywność ale juz skontrargumentowalem, ze to samo daje inferencja typow w takim przykladowym Kotlinie

"Wiecej patternow"? Ale jakich?

lion137 napisał(a):

Skoro język ma mniej ograniczeń, to ma więcej patternów, Peter Norvig o tym pisał. O jakich anty patternach piszesz? Może że ktoś pisze shit code, ale co tu ma dynamiczność/statyczność do rzeczy?

Jeśli masz na myśli wzorce projektowe to jest dokładnie odwrotnie. Im język nędzniejszy tym więcej patternów potrzeba.
Idealnie to u widać w przypadku np.:
Scala vs Java.

Wzorzec projektowy to taki eufemizm na copy paste, czegoś nie ma w języku i nie da się zrobić jako funkcję biblioteczną, wiec klepiemy jakiś powtarzalny boiler-plate.
(przykładem może być np. visitor, który w Scali czy haskellu można ogarnąć biblioteką  (see resursion schemes - matryoshka, można sie kłocić, ale wiele przypadków użycia visitora to właśnie zastępuje).

Więc czy Python ma jakieś wady jako język skoro zdominował cały świat

Jest popularny bo był preinstalowany na niemal każdym linuksie a nie dlatego, że był jakiś wybitny. Zaczęło się od maszyn z gnome i KDE a potem to już nawet na serwery go pchali. A wady ma jak najbardziej, każdy większy projekt wygląda jak jakaś kaszanka. Może doktorzy na uniwerkach już rozpracowali ten paradoks, przez który języki z luźniejszą składnią czyta się lepiej przy wzroście złożoności (chociaż taki perl bylby wyjątkiem) a języki składniowo trochę bardziej restrykcyjne, jak python, zamieniają się w jaką niezgragną kulkę tekstu.

A do jakiejś dominacji to mu daleko, to język który utknął w małej narzędziówce i oprócz ML czy AI nic poważnego się w nim nie robi. A to ML czy AI to też głównie prototypowanie bo deploy to jednak w czymś poważnym.

kelog napisał(a):

To co lepsze do deployu?

Modele deep learning robi się w Pythonie, ale można też w C++, w innych językach też, ale to nie ma znaczenia.
Główne serce, backend tensorflow czy pytorch jest napisany w C++/C/CUDA i często sporo innych rzeczy CPU/GPU.

I teraz tak ktoś napisze, że python wolny itp. itd.
To nie wie w ogóle jak to działa od wewnątrz.
W pythonie robisz załaduj model, to on odpala tylko przejście do backendu dając tylko path i tyle.
Teraz już kod się wykonuje w C++, tam pobiera z dysku, alokuje pamięć za pomocą cudamalloc, przekopiowuje dane.
Potem te dane tam wiszą aż nie zwolnisz pamięci, czyli do końca życia serwera, bo za dużo czasu zabiera wczytywanie modelu.

Tak normalnie to generujesz sobie obliczenia, z tego masz graf operacji, możesz skompilować go jitem i mieć native speed z optymalizacjami.
Jak masz np. już nauczony model, to i chcesz tylko dać na produkcję inferencyjny model, to zależy od platformy np. przeglądarka czy mobile, to konwertujesz ten model do formatu ONNX, a jeśli chcesz na serwer, cloud, to zapisujesz parametry modelu wagi i model modelu.

Potem np. zależnie od technologii taki pytorch ma torchserve i uruchamia się nim .mar model archive, który generujemy sobie przy pomocy tych parametrów wag i modelu.
Trzeba jeszcze handler dodać do obsługi gdyż każdy model może być inny, wymagać jakiegoś wstępnego przetworzenia danych, nie jest oczywiste co wykonać.
Więc definiuje się co zrobić z otrzymanym jsonem, large language model wykonuje obliczenia na tokenach, a my mamy tekst, więc w preprocess etapie, uruchamiamy binda do backendu, który na zapytaniu wykona tokenizację w przypadku tekstu, dla obrazów może być np. zmiana rozdzielczości itp.

Potem w następnym etapie trzeba wykonać inferencję, przekazujemy dane z preprocessingu te tokeny wywołując inferencję na modelu i na postprocessingu po prostu mapujemy zpowrotem tokeny do tekstu, też przez backend bo python jest zawolny żeby dla tylu tysięcy elementów robić to na wirtualnej maszynie, wykonuje tą operację natywnie w C++.
Takie wywołanie backendu to jest czas typu 10 microsekund, praktycznie żadne obliczenia nie są robione po stronie python, on co najwyżej przekazuje referencje obiektu, na którym backend operuje i wszystko jest po stronie C++.

Taki gotowy model opakowujesz w docker/pod i zależnie co użyjesz np. jak użyłeś torchserver to on tworzy po prostu rest api, do którego się dobijasz tym portem do kontenera, wysyłając jsona z requestem inputa i otrzymując też jsona z odpowiedzią.

To też nie jest jedyny sposób wykonania tego, ale jak masz kilka takich kontenerów, zrobisz jakiś loadbalancer pomiędzy nie wszystkie, to możesz duży ruch obsłużyć, najlepiej dać jakiś queue i modelami ściągać z tej kolejki jak skończą wykonywać zadanie i skończone wrzucać do innego topica, z którego potem serwer to obsługujący ściąga.
A jakiś z przodu np. główny serwer w springu czy czymś innym, zapytania użytkowników rejestruje i po otrzymaniu odpowiedzi odpisuje im.
Można też zrobić tak, że zamiast wysyłać od razu całą odpowiedź, to można przy każdym przejściu GPT generative pretrained transformer, jedno przejście to jeden nowy token wywnioskowany i je odsyłać od razu wtedy w czasie rzeczywistym widać jak zdanie jest tworzone, nie ma zbędnego laga gdy trzeba czekać na całą wypowiedź, a to już potem websocketem można prosto przesłać do frontendu komunikacją dwukierunkową.