Jakie wady ma Python 3?

Zainspirowany tematem Jakie wady ma C# i .NET? chciałbym usłyszeć wasze opinie na temat wad Pythona :) Skupmy się na Pythonie 3.
Zaczynam:

Powszechne używanie metaklas (np. modele, formularze w Django) i dynamicznej modyfikacji obiektów (boto3) uniemożliwiają/bardzo utrudniają skuteczne otypowanie niektórych bibliotek.

Dict driven development. Widziałem wiele projektów w których budowanie dicta jest rozstrzelone w 10 różnych plikach, a potem interesująca nas funkcja jest wywoływana z parametrami **params, co strasznie utrudnia debugowanie - nie wiadomo skąd co się bierze. Dodajmy do tego wywoływanie metody na podstawie jej nazwy przekazanej gdzieś jako string i ni cholery bez przechodzenia krok po kroku w debuggerze nie dowiemy się co tam się dzieje.

Global Interpreter Lock w CPythonie.

Python 3 jest wolniejszy od najnowszego PHP 7 ;( wiele źródeł, benchmarków na które się natknąłem wieszczy tę informację

Jedną z wad Pythona jest jego popularność. Później dużo programersów takich pisze o jego wadach i nie wiadomo, czy nagle programy w nim pisane przestaną działać, czy coś, no w każdym razie, stres jest. Później ciężko pisać, mając przed oczami te wszystkie wymienione wady i znowu stres jest. A później, by się usprawiedliwić, to już człowiek sam zakłada wątki na forach i pyta o wady, co by się utwierdził w przekonaniu.

Dla mnie dyskwalifikacją Pajtona jest Funkcje w Pythonie nie posiadają sprecyzowanych początków i końców oraz żadnych nawiasów służących do zaznaczania, gdzie funkcja się zaczyna, a gdzie kończy. Jedynym separatorem jest dwukropek[...]Bloki kodu definiujemy poprzez wcięcia - https://pl.wikibooks.org/wiki/Zanurkuj_w_Pythonie/Wci%C4%99cia_kodu

• Parcie na programowanie asynchroniczne, async def, await i tym podobne, nieco podzieliło to społeczność języka, nie wszyscy to lubią.
• Stosunkowo wolny
• Niektóre elementy języka są mało intuicyjne (np. for-else).
• 10 lat po premierze Pythona 3, a ciągle mnóstwo kodu jest w 2.x. Złamanie wstecznej kompatybilności między wersjami okazało się bolesne i do dziś boli.

1. Python jest za duży. Lekko podpity Hettinger powiedział, że na świecie jest tylko dwóch ludzi, którzy w całości ogarniają, co dzieje się pod maską i on nie jest jednym z nich. Nie był zadowolony z kierunku, w którym zmierza język i społeczność. Nagranie zostało niestety usunięte. https://twitter.com/raymondh/status/959358630377091072

2. Przeciekające abstrakcje.

>>> int.__add__
<slot wrapper '__add__' of 'int' objects>
>>> 

1. Funkcja max zwraca pierwszy największy element. (Powinna zwracać ostatni największy.)

2. Opcja -Wdefault nie ustawia domyślnych warningów.

Dynamiczne typowanie. Inferencja + statyczne typowanie > statyczne typowanie >> dynamiczne typowanie

scibi92 napisał(a):

Dynamiczne typowanie. Inferencja + statyczne typowanie > statyczne typowanie >> dynamiczne typowanie

Jesteś bardzo nie na bieżąco. Od 3.6 jest możliwość deklarowania typu, a mypy czy PyCharm ładnie łapie errory bez potrzeby wykonywania kodu.

Mózg napisał(a):

1. Przeciekające abstrakcje.

Kopiuj

>>> int.__add__
<slot wrapper '__add__' of 'int' objects>
>>> 

O co chodzi z tymi przeciekającymi abstrakcjami? To, że prywatność przez konwencję nazewniczą?

1. Funkcja max zwraca pierwszy największy element. (Powinna zwracać ostatni największy.)

Dlaczego powinna ostatni największy?

Podstawową wadą Pythona jest wydajność, może w jakiejś aplikacji webowej, to nie ma znaczenia, ale, jak przyjdzie napisać wydajny kod (np. scientific computing), to korzystamy tylko z bibliotek, które są Pythonowymi nakładkami na C/C++. Jakikolwiek kawałek Pythona może zwolnić działanie programu i kilkusetkrotnie - chcąc coś zakodować trzeba wychodzić z Pythona do innych języków, innych środowisk, debugera, etc.. - niesłychanie uciążliwe.

Ja pozwolę sobie podpiąć się pod pytanie, bo chodziło mi to po głowie od jakiegoś czasu. Mianowicie czemu uważa się że Python jest dobry do prototypowania ale nie do większych, produkcyjnych aplikacji? Co np. przemawia za tym żeby nie stosować Pythona do napisania jakiegoś Web API (podkreślam że większego a nie jakiś prosty CRUD)?

Aventus napisał(a):

Ja pozwolę sobie podpiąć się pod pytanie, bo chodziło mi to po głowie od jakiegoś czasu. Mianowicie czemu uważa się że Python jest dobry do prototypowania ale nie do większych, produkcyjnych aplikacji? Co np. przemawia za tym żeby nie stosować Pythona do napisania jakiegoś Web API (podkreślam że większego a nie jakiś prosty CRUD)?

Tak zazwyczaj uważają programiści, którzy normalnego IDE nie widzieli i testów nigdy nie pisali. I w ogóle nie odróżniają pewnie problemów po stronie architektury, od problemów stricte z samym językiem. Oni od razu wiedzą, że będą walczyć w swoim crudzie o cenne nanosekundy i Python się nie nada.

Oni od razu wiedzą, że jest zbyt słabo typowalny (IDE+lintery+mypy właśnie), bo jak ich nie przypilnuje tak jak np. kompilator Rusta, to pewnie ich projekt na 100 linii w porywach, w którym piszą tylko oni sami, się posypie z nadmiaru błędów. I winny będzie wyłącznie Python, a nie architektura czy np. ich styl kodowania.

TurkucPodjadek napisał(a):

Oni od razu wiedzą, że jest zbyt słabo typowalny (IDE+lintery+mypy właśnie), bo jak ich nie przypilnuje tak jak np. kompilator Rusta, to pewnie ich projekt na 100 linii w porywach, w którym piszą tylko oni sami, się posypie z nadmiaru błędów. I winny będzie wyłącznie Python, a nie architektura czy np. ich styl kodowania.

Myślę, że typowy projekt w korpo ma > 100k linii kodu łącznie (nie wliczając komentarzy i pustych linii). Jeśli to jest np monolit to jest to wszystko w jednym projekcie. Przy takiej skali statyczne typowanie jest bardzo pomocne. Projekty na 100 linii to raczej skrypty do automatyzacji pewnych prostych powtarzających się czynności i te są zwykle w bashu czy Pythonie.

Zresztą możemy zrobić jakieś proste wyliczenia. Dla przykładu mamy 5 letni projekt z 5 programistami. Programista pracuje 200 dni w roku i codziennie dodaje efektywnie 20 linijek kodu (czyli jest to wartość netto = ilość linii dodanych - ilość linii usuniętych). Ostatecznie mamy: 5 * 5 * 200 * 20 = 100k linii kodu.

@TurkucPodjadek: nie wiem po co ta złość, po prostu wyraziłem swoje zdanie że dynamiczne typowanie utrudnia pracę. Na pewno taki Python może być sensowny do pewnych zastosowań np. AI, skrypty jako alteratywa dla Bashu. Po prostu chodzi o to że napisanie List<Products> products, zamiast po prostu products nie spowoduje że strace 20 godzin. Ok, może są narzędzia do analizy kodu, ale fajnie jest jak kod już jest w miare zrozumiały bez nich, np. jak widzisz zmiany na githubie.
Ja ogólnie nie wierze że jest coś takiego jak doskonały język ogólnego przeznaczenia i np. lubię Grooviego który jest bardziej dynamicznym językiem niż Python ale nie użyłbym go do stworzenia projektu na 20k kodu, tylko do testów, jakiś prostych skryptów czy małych projekcików :)

Jak dla mnie wady Pythona 3 to powolność, dynamiczne typowanie, nie jest kompilowany. Gdyby Crystal nie miał takiej składni jak Ruby z tym end które mi się nie podoba. Byłby idealnym zamiennikiem Pythona. Ma wszystko to czego brakuje Pythonowi.
https://crystal-lang.org

Ok, trochę będę s**ł do własnego gniazda bo choć już dawno nie babrałem zawodowo łapek w Pythonie to wciąż mam do niego sentyment:

• dynamiczne typowanie - potrafi sprawić problemy, dlatego staram się je jako tako łatać type hintami i innymi takimi
• wielowątkowość - żeby w 2019 domyślne interpretery dalej wycinały wykonanie równoległe... na szczęście Python ma całkiem znośne biblioteki do zrównoleglania na procesach. W każdym razie concurrent.futures są całkiem OK, bo multiprocessing to już tak sobie, w sumie nigdy nie wiesz (dosłownie) kiedy Ci umrze proces
• wydajność - nie ma co się oszukiwać, jest powolny. Da się to podratować kompilując do binarki (tak, da się) czy używając JIT np. z numba albo hakując bibliotekami które pod spodem mają C / C++ / Fortran / Go / Ada (takie też chyba kiedyś znalazłem)...
• ... ale im dalej w las i więcej kombinowania i hakowania w imię wydajności tym więcej problemów, bo np. mimo interpretowanego języka uzależniasz się nie dość od platformy, to jeszcze od kolejności dynamicznego importu N różnych skompilowanych libek, które pod spodem zaciągają wybiórczo Twoje dependencje. Mówię tu szczególnie o różnych geopandasach, shapely, fionach itp. które jak dobrze pamiętam narobiły mi z tym kiedyś rabanu.

Z mojej strony największe wady:3

1. Performance szczególnie bolesne bardzo kosztowne pętle co automatycznie wyklucza pisanie czegoś sensownego w czystym pythonie i trzeba schodzic do Cythona. Ale największym problemem nie jest sam performance bo bez problemu można wykorzystać setki bibliotek które sprawiają że python staje się szybszy niż np. Java (w obliczeniach numerycznych) ale problemem jest okrutnie ujowa wielowątkowość i tutaj już nie ma za bardzo co zrobić.

Natomiast od jakiegoś czasu jest parę fajnych inicjatyw które się tym zajmują szczególnie numba i dask. numba

1. Bardzo powolny rozwój samego języka od 3.5 praktycznie nie było żadnych przełomowych zmian w języku i przy 3.8 dalej nic "magicznego" nie wchodzi.

2. Rozrośnięte zależności w bibliotekach coś w stylu noda tylko na mniejszą skalę ale dalej "toksyczne"

3. Brak sensownego przywództwa w community, od jakiegoś czasu nastąpiła "demokratyzacja" języka i zajmowanie się sprawami typu master - slave i innym tego typu rakiem zamiast sprawami typu wydajność.

Od jakiegoś czasu mocno ograniczyłem pythona jako główny język na rzecz Juli oraz Rusta natomiast nie ma co ukrywać liczba genialnych bibliotek w Pythonie jest na tyle duża że język będzie rozwijał się przez najbliższe lata bo nie opłaca się pisać całego nowego środowiska w nowym jęzku o ile nie jesteś wielkim korpo.

wolny i strasznie dynamiczny (rzeczy typu monkey patching itp), ale mimo wszystko super jezyk.

edit. no i strasznie jezyk sie rozjezdza :( te cale the zen of python jest swietne, ale od 3.6 (?) powoli jezyk jest zasmiecany 'ladniejszymi' rozwiazaniami i puchnie w np 3 sposoby na printowanie stringa...

OT, sorry

Czy Python nie stał się de facto standardem w nauczaniu programowania? Nie tylko na świecie ale i w Polsce?

Widzę, że sporo piszących uważa za wadę dynamiczne typowanie; to chyba nie OK, język, który jest dynamiczny krytykować właśnie za to.

Krytykują za dynamiczne typowanie jako takie. Fajnie i szybko tak kod (dynamic typing) się pisze - chyba każdy się zgodzi, ale IMO trudniej analizuje i utrzymuje.

my_varaible = my_variable + 1 // WTF?!?!? ;)

Dla mnie łatwiej, kiedy IDE da mi znać, że się chyba wygłupiam z tą "varaible", niż gdyby miał siedzieć cicho, bo w końcu koder jego pan i my_varaible równie dobre jak my_variable.

Po stronie maszyny wirtualnej kod statycznie typowany da się prościej (efektywniej) optymalizować ale nie znam się, może się okazać, że to teraz już nie jest problemem dla wydajności.

Nie znam Pythona, nie wiem czy varaible pójdzie do window, do global, czy nie wiem gdzie (myślę o JS & Node).

okazało że konieczne jest sprawdzenie jednej listy i drugiej pod kątem wyłonienia permutacji, resztę kodu już miałem w pythonie no to już tylko wystarczyło dorzucić tam taki moduł, od razu sobie pomyślałem o itertools bo co może pójść źle, ale okazało się że zrobiłem taki interes że zyskałem ok godzinę przy pisaniu w pythonie zamiast w c++, a potem kod wykonania zamiast godziny wynosił jakoś ponad tydzień.

Mała uwaga do dyskutujących, to nie wina języka, że czesto jesteście niekompetentni w danej technologii i nie potraficie poprawnie rozwiązać zadania. To że komuś coś działa "za wolno" itp. często wynika tylko z braku wiedzy i doświadczenia i nie zwalałbym od razu wszystkiego na ograniczenia języka. :)

cmd napisał(a):

okazało że konieczne jest sprawdzenie jednej listy i drugiej pod kątem wyłonienia permutacji, resztę kodu już miałem w pythonie no to już tylko wystarczyło dorzucić tam taki moduł, od razu sobie pomyślałem o itertools bo co może pójść źle, ale okazało się że zrobiłem taki interes że zyskałem ok godzinę przy pisaniu w pythonie zamiast w c++, a potem kod wykonania zamiast godziny wynosił jakoś ponad tydzień.

Mała uwaga do dyskutujących, to nie wina języka, że czesto jesteście niekompetentni w danej technologii i nie potraficie poprawnie rozwiązać zadania. To że komuś coś działa "za wolno" itp. często wynika tylko z braku wiedzy i doświadczenia i nie zwalałbym od razu wszystkiego na ograniczenia języka. :)

Przecież wiadomo, że większość krytykujących pythona pisze kod doskonały, więc jedynie ograniczenia samego języka ich blokują przed pisaniem świetnego softu. Więc jak śmiesz zarzucać komuś niekompetencje? :-)

Aventus napisał(a):

Ja pozwolę sobie podpiąć się pod pytanie, bo chodziło mi to po głowie od jakiegoś czasu. Mianowicie czemu uważa się że Python jest dobry do prototypowania ale nie do większych, produkcyjnych aplikacji? Co np. przemawia za tym żeby nie stosować Pythona do napisania jakiegoś Web API (podkreślam że większego a nie jakiś prosty CRUD)?

To, że Python nie nadaje się do dużych rzeczy to bajka wymyślona przez wojowników klawiatury, którzy na co dzień klepią nudne crudy w Javie (nie będę przytaczał po nickach, wszyscy wiedzą o kogo chodzi :P :P :P). W rzeczywistości reddit został napisany w Pythonie. W tym języku powstał również Youtube, gra Eve Online czy Dropbox. Osobiście byłem w zespole rozwijającym serwis transakcyjny największego polskiego banku w tym języku.

Oczywiście w Pythonie można przyjąć postawę defensywną (mypy+adnotacje, rzucanie własnych wyjątków, kontrakty pre/post, układanie kodu w pierwszej kolejności pod testy, no i głównie kodowanie logiki za pomocą klas) i zapewne czasem jest to jedyne wyjście jeśli pracuje się jak małpa, wśród małp na polu minowym. Typowo obawa przed bugami oraz coraz trudniejszym utrzymaniem kodu sprawia, że przypadkowy programista widzi jedynie opcję w której pythona zatopia się w betonie, aby uzyskać twór chociaż trochę zbliżony do javy/c#.

Tego typu motyw ma ten plus, że w pracy można łatwo innym osobom pokazać jak wiele w ogóle umiemy, jak ciężko pracujemy itp. Ale nic poza tym! Wydaje mi się, że największą wadą Pythona jest to, że to nie jest język pod inżyniera stworzony. Tutaj nie ma oszałamiającej wydajności, no i też wspomniane próby betonu zbyt dobrze nie wypadają.

Ze swojej strony chciałbym tylko dodać, że to co jednym nie leży drugim jak najbardziej odpowiada, i tutaj kilka uwag z mojej strony:

Znam kilka osób, które piszą wyjątkowo dobry kod w pythonie i jednocześnie ciekawy zbieg okoliczności: żadna z tych osób nie kończyła studiów IT, natomiast każda z tych osób programowała kilka lat w innych językach + w dużym stopniu jest bardziej humanistą niż ścisłowcem.

Myślę, że w Pythonie bardziej zwraca się postawa, gdy piszesz projekt tak jakbyś chciał stworzyć intrygującą książkę. To jest dobry język, gdy ważysz słowa, gdy skupiasz uwagę na intencjach, gdy zwacasz uwagę na kontekst i odpowiednio kalkulujesz ryzyko związane z poziomem abstrakcji. No i najlepiej jest jak nie ściemniasz i nie traktujesz czytelnika swego kodu jak głupca :-)

Python powinien sprzedawać się nie tylko jako prosty język (w sensie łatwy na start), ale również jako język, który umożliwia pisanie prostego i przejrzystego oprogramowania. To jest ogromna różnica, i łatwo ją zobrazować. Dla przykładu w JavaScript początki są banalne, a im dalej w las to prawdziwa sztuka pisać dobry kod.

Pisanie kodu w pythonie ukształtowało styl mojego kodu. Na początku miałem głównie klasy, potem z czasem rozdrabniałem je na mniejsze, a potem z czasem okazywało się, że najlepsze klasy to takie, które mają jednoznaczną rolę, a ich interejs obejmuje nie więcej niż jedną czy dwie metody. Potem wychodziło, że 90% tych klas lepiej mogę zapisać jako funkcję, funkcję wyższego rzędu, domknięcie, dekorator, kontekst manager czy generator.

Myślę, że z punktu samego pisania kodu Python to udany mix uproszczonego lispa i javy w jednym. Dzięki pythonowi doceniłem programowanie w lisp :-)

Python to język super dla osób, ktore lubią uczyć się poprzez eksplorację. Python ma wiele bibliotek, z różnych obszarów więc poza typowym rzemiosłem można wynieść wiele wiedzy i nowych umiejętności z innych dziedzin.

Life is short, use python :-)

@yarel

O co chodzi z tymi przeciekającymi abstrakcjami?

Slot wrapper to szczegół implementacyjny. Co więcej, nie powinieneś wiedzieć, że coś takiego jak slot wrapper w ogóle istnieje.

Dlaczego powinna ostatni największy?

Który element w posortowanej liście jest największy? Ostatni. min i max powinny być symetryczne.

Wtedy zamiast

def clamp(x, lo, hi):
    return min(max(x, lo), hi)

mógłbym wyrazić problem naturalnie

def clamp(x, lo, hi):
    return min(max(lo, x), hi)

Dla mnie z minusow (uzytykuje specyficznie, jedynie male skrypty narzedziowe). Ze trzeba sie troche wiecej napisac niz w 2.7 zwlaszcza jak chodzi o uzycie print :)

No i do tego pare rzeczy robi sie teraz troche inaczej a sila przyzwyczajenia zostaje :)

WhiteLightning napisał(a):

Dla mnie z minusow (uzytykuje specyficznie, jedynie male skrypty narzedziowe). Ze trzeba sie troche wiecej napisac niz w 2.7 zwlaszcza jak chodzi o uzycie print :)

Oj tam panie, teraz idzie wszystko ku dobremu, śmigasz sobie f stringach:

>>> name = "Guido"
>>> age = 63
>>> f"Hello, {name}. You are {age}."
'Hello, Guido. You are 63.'

Python jest dobry, ale mógłby mieć wydajność Rust lub Swift, a Numba to nakładka i do tego słaba.