Jakie są wady Pythona? [Zamknięte]

Python wydaje się teraz wściekły i nie bez powodu - ponieważ jest to naprawdę język, którym prawie się cieszy, gdy dostaje się nowy problem do rozwiązania. Ale, jak powiedział kiedyś mądry człowiek (nazywając go mędrcem tylko dlatego, że nie mam pojęcia, kto to powiedział; nie jestem pewien, czy on był w ogóle taki mądry), aby naprawdę znać język, którego nie tylko się zna składnia, design itp., zalety, ale także jego wady. Żaden język nie jest idealny, niektóre są po prostu lepsze niż inne.

Jakie byłyby Twoim zdaniem obiektywne wady Pythona.

Uwaga: nie pytam o porównanie języków (tj. C # jest lepszy niż Python, ponieważ ... yadda yadda yadda) - bardziej obiektywna (do pewnego stopnia) opinia, które funkcje językowe są źle zaprojektowane, czy to, co może niektórych brakuje w nim i tak dalej. Jeśli trzeba użyć innego języka jako porównania, ale tylko w celu zilustrowania kwestii, która w innym przypadku byłaby trudna do opracowania (tj. Dla ułatwienia zrozumienia)

Używam Pythona dość regularnie i ogólnie uważam, że jest to bardzo dobry język. Niemniej jednak żaden język nie jest idealny. Oto wady w kolejności według mnie osobiście:

1. Jest wolny Mam na myśli naprawdę, bardzo powoli. Wiele razy to nie ma znaczenia, ale zdecydowanie oznacza, że ​​będziesz potrzebować innego języka dla bitów o kluczowym znaczeniu dla wydajności.

2. Funkcje zagnieżdżone w pewnym sensie zasysają to, że nie można modyfikować zmiennych w zakresie zewnętrznym. Edycja: Nadal używam Pythona 2 ze względu na obsługę bibliotek, a ten błąd w projekcie denerwuje mnie, ale najwyraźniej został naprawiony w Pythonie 3 z powodu nielokalnej instrukcji. Nie mogę się doczekać, aż biblioteki, których używam, zostaną przeniesione, aby ten błąd mógł zostać przesłany na stos popiołów historii na dobre.

3. Brakuje kilku funkcji, które mogą być przydatne do biblioteki / kodu generycznego, a IMHO upraszcza ekstremalne niezdrowe sytuacje. Najważniejsze, jakie mogę wymyślić, to typy wartości zdefiniowane przez użytkownika (domyślam się, że można je tworzyć za pomocą magii metaklasy, ale nigdy nie próbowałem) i parametr funkcji ref.

4. To daleko od metalu. Potrzebujesz pisać operacje na wątkach, kod jądra czy coś takiego? Powodzenia.

5. Chociaż nie przeszkadza mi brak możliwości wychwytywania błędów semantycznych z góry jako kompromis dla dynamizmu, który oferuje Python, chciałbym, aby istniał sposób na wychwycenie błędów składniowych i głupich rzeczy, takich jak błędne wpisywanie nazw zmiennych bez konieczności uruchamiania kodu.

6. Dokumentacja nie jest tak dobra, jak języki takie jak PHP i Java, które mają silne zaplecze korporacyjne.

Nienawidzę tego, że Python nie potrafi rozróżnić deklaracji od użycia zmiennej. Aby to zrobić, nie potrzebujesz pisania statycznego. Byłoby po prostu miło powiedzieć „jest to zmienna, którą celowo deklaruję i zamierzam wprowadzić nową nazwę, to nie jest literówka”.

Ponadto zwykle używam zmiennych Python w stylu jednokrotnego zapisu, to znaczy traktuję zmienne jako niezmienne i nie modyfikuję ich po pierwszym przypisaniu. Dzięki takim funkcjom, jak przetwarzanie list, jest to niezwykle łatwe i ułatwia śledzenie przepływu kodu.

Nie mogę jednak udokumentować tego faktu. Nic w Pythonie nie uniemożliwia mi nadpisywania lub ponownego wykorzystywania zmiennych.

Podsumowując, chciałbym mieć dwa słowa kluczowe w języku: vari let. Jeśli piszę do zmiennej niezadeklarowanej przez żadną z nich, Python powinien zgłosić błąd. Ponadto letdeklaruje zmienne jako tylko do odczytu, podczas gdy varzmienne są „normalne”.

Rozważ ten przykład:

x = 42    # Error: Variable `x` undeclared

var x = 1 # OK: Declares `x` and assigns a value.
x = 42    # OK: `x` is declared and mutable.

var x = 2 # Error: Redeclaration of existing variable `x`

let y     # Error: Declaration of read-only variable `y` without value
let y = 5 # OK: Declares `y` as read-only and assigns a value.

y = 23    # Error: Variable `y` is read-only

Zauważ, że typy są nadal niejawne (ale letzmienne są statycznie typowane dla wszystkich celów i celów, ponieważ nie można ich przywrócić do nowej wartości, podczas gdy varzmienne mogą być nadal dynamicznie typowane).

Wreszcie wszystkie argumenty metody powinny być automatycznie let, tzn. Powinny być tylko do odczytu. Zasadniczo nie ma żadnego powodu, aby modyfikować parametr, z wyjątkiem następującego idiomu:

def foo(bar = None):
    if bar == None: bar = [1, 2, 3]

Można to zastąpić nieco innym idiomem:

def foo(bar = None):
    let mybar = bar or [1, 2, 3]

Moja główna skarga dotyczy wątków, które w wielu okolicznościach nie są tak wydajne (w porównaniu z Javą, C i innymi) z powodu globalnej blokady interpretera (patrz „Wewnątrz Python GIL” (link PDF) )

Istnieje jednak interfejs wieloprocesowy, który jest bardzo łatwy w użyciu, jednak korzystanie z pamięci dla tej samej liczby procesów w porównaniu do wątków będzie większe, lub trudne, jeśli masz dużo wspólnych danych. Korzyścią jest jednak to, że gdy program działa z wieloma procesami, może być skalowany na wielu komputerach, czego nie może zrobić program wielowątkowy.

Naprawdę nie zgadzam się z krytyką dokumentacji, uważam, że jest ona doskonała i lepsza niż większość, jeśli nie wszystkie główne języki.

Ponadto możesz złapać wiele błędów środowiska uruchomieniowego, uruchamiając pylint .

Prawdopodobnie brak pisania statycznego, który może wprowadzić pewne klasy błędów w czasie wykonywania , nie jest wart dodatkowej elastyczności, jaką zapewnia pisanie kaczką.

Wydaje mi się, że zorientowane obiektowo części Pythona są jakby „przykręcone”. Cała potrzeba jawnego przekazania „siebie” każdej metodzie jest symptomem tego, że jej składnik OOP nie został wyraźnie zaplanowany , można powiedzieć; pokazuje także czasami brudzące zasady określania zakresu Pythona, które zostały skrytykowane w innej odpowiedzi.

Edytować:

Kiedy mówię, że zorientowane obiektowo części Pythona wydają się „przykręcone”, mam na myśli to, że czasami strona OOP wydaje się niespójna. Weźmy na przykład Ruby: w Ruby wszystko jest obiektem, a ty wywołujesz metodę przy użyciu znanej obj.methodskładni (oczywiście z wyjątkiem przeciążonych operatorów); w Pythonie wszystko też jest obiektem, ale niektóre metody wywołuje się jako funkcję; tzn. przeciążasz, __len__aby zwrócić długość, ale wywołujesz ją, używając len(obj)bardziej znanego (i spójnego) obj.lengthwspólnego w innych językach. Wiem, że istnieją powody tej decyzji projektowej, ale ich nie lubię.

Ponadto w modelu OOP Pythona brakuje jakiejkolwiek ochrony danych, tzn. Nie ma prywatnych, chronionych i publicznych członków; możesz je naśladować za pomocą metod _i __przed nimi, ale to trochę brzydkie. Podobnie, Python nie do końca rozumie aspekt OOP w zakresie przekazywania wiadomości.

Czego nie lubię w Pythonie:

1. Wątki (wiem, że już o tym wspominano, ale warto o nich wspomnieć w każdym poście).
2. Brak obsługi wieloliniowych funkcji anonimowych ( lambdamoże zawierać tylko jedno wyrażenie).
3. Brak prostego, ale potężnego Funkcja wejścia czytania / klasa (jak cinczy scanfw C ++ i C lub ScannerJava).
4. Domyślnie wszystkie ciągi znaków nie są Unicode (ale są poprawione w Pythonie 3).

Domyślne argumenty ze zmiennymi typami danych.

def foo(a, L = []):
    L.append(a)
    print L

>>> foo(1)
[1]
>>> foo(2)
[1, 2]

Zwykle jest to wynikiem pewnych subtelnych błędów. Myślę, że byłoby lepiej, gdyby tworzył nowy obiekt listy za każdym razem, gdy wymagany był domyślny argument (zamiast tworzyć pojedynczy obiekt do użycia dla każdego wywołania funkcji).

Edycja: To nie jest duży problem, ale kiedy coś trzeba odwołać w dokumentacji, zwykle oznacza to, że jest to problem. Nie powinno to być wymagane.

def foo(a, L = None):
    if L is None:
        L = []
    ...

Zwłaszcza gdy powinno to być ustawienie domyślne. To po prostu dziwne zachowanie, które nie odpowiada oczekiwaniom i nie jest przydatne w wielu okolicznościach.

Niektóre funkcje Pythona, które czynią go tak elastycznym jak język programowania, są również postrzegane jako główne wady tych, które są wykorzystywane do analizy statycznej „całego programu” przeprowadzanej przez proces kompilacji i łączenia w językach takich jak C ++ i Java.

• Domniemana deklaracja zmiennych lokalnych

Zmienne lokalne są deklarowane za pomocą zwykłej instrukcji przypisania. Oznacza to, że powiązania zmiennych w dowolnym innym zakresie wymagają od kompilatora jawnej adnotacji (globalne i nielokalne deklaracje dla zakresów zewnętrznych, notacja dostępu do atrybutów na przykład dla zakresów). To znacznie zmniejsza ilość płyty kotłowej potrzebnej przy programowaniu, ale oznacza, że ​​do przeprowadzania kontroli obsługiwanych przez kompilator w językach wymagających wyraźnych deklaracji zmiennych potrzebne są narzędzia do analizy statycznej innych firm (takie jak płatki py).

• Obsługiwane jest „łatanie małp”

Zawartość modułów, obiektów klasy, a nawet wbudowanej przestrzeni nazw można modyfikować w czasie wykonywania. Jest to niezwykle potężny, umożliwiający wiele niezwykle przydatnych technik. Jednak ta elastyczność oznacza, że ​​Python nie oferuje niektórych funkcji wspólnych dla statycznych języków OO. W szczególności parametr „self” dla metod instancji jest raczej jawny niż niejawny (ponieważ „metod” nie trzeba definiować wewnątrz klasy, można je później dodać poprzez modyfikację klasy, co oznacza, że ​​nie jest to szczególnie praktyczne niejawnie przekazać odwołanie do instancji) i kontroli dostępu do atrybutu nie można łatwo egzekwować w zależności od tego, czy kod znajduje się „wewnątrz”, czy „poza” klasą (ponieważ to rozróżnienie istnieje tylko podczas wykonywania definicji klasy).

• Daleko od metalu

Dotyczy to również wielu innych języków wysokiego poziomu, ale Python ma tendencję do wyabstrahowywania większości szczegółów sprzętowych. Języki programowania systemów, takie jak C i C ++, są nadal znacznie lepiej przystosowane do obsługi bezpośredniego dostępu do sprzętu (jednak Python z przyjemnością porozmawia z tymi za pomocą modułów rozszerzeń CPython lub, bardziej przenośnie, za pośrednictwem ctypesbiblioteki).

1. Korzystanie z wcięcia bloków kodu zamiast {} / begin-end, cokolwiek.
2. Każdy nowszy współczesny język ma odpowiednie zakresy leksykalne, ale nie Python (patrz poniżej).
3. Chaotyczne dokumenty (porównaj z dokumentacją Perl5, która jest znakomita).
4. Kaftan bezpieczeństwa (jest tylko jeden sposób, aby to zrobić).

Przykład zepsutego określania zakresu; transkrypcja z sesji tłumacza:

>>> x=0
>>> def f():
...     x+=3
...     print x
... 
>>> f()
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment

globali nonlocalwprowadzono słowa kluczowe, aby załatać tę głupotę projektu.

Uważam, że kombinacja składni obiektowej this.method()i method(this)składni proceduralnej / funkcjonalnej Pythona jest bardzo niepokojąca:

x = [0, 1, 2, 3, 4]
x.count(1)
len(x)
any(x)
x.reverse()
reversed(x)
x.sort()
sorted(x)

Jest to szczególnie złe, ponieważ duża liczba funkcji (a nie metod) jest po prostu zrzucana do globalnej przestrzeni nazw : metody odnoszące się do list, ciągów, liczb, konstruktorów, metaprogramowania, wszystkie zmieszane w jedną dużą listę posortowaną alfabetycznie.

Przynajmniej w językach funkcjonalnych, takich jak F #, wszystkie funkcje mają odpowiednio rozmieszczone nazwy w modułach:

List.map(x)
List.reversed(x)
List.any(x)

Więc nie wszyscy są razem. Co więcej, jest to standard przestrzegany w całej bibliotece, więc przynajmniej jest spójny.

Rozumiem powody, dla których warto wykonać funkcję vs metoda , ale nadal uważam, że złym pomysłem jest mieszanie ich w ten sposób. Byłbym znacznie szczęśliwszy, gdyby przestrzegano składni metody, przynajmniej w przypadku typowych operacji:

x.count(1)
x.len()
x.any()
x.reverse()
x.reversed()
x.sort()
x.sorted()

Niezależnie od tego, czy metody mutują, czy nie, posiadanie ich jako metod na obiekcie ma kilka zalet:

• Jedno miejsce do wyszukiwania „typowych” operacji na typie danych: inne biblioteki / etc. mogą mieć inne wymyślne rzeczy, które mogą zrobić z typami danych, ale wszystkie operacje „domyślne” są w metodach obiektu.
• Nie musisz powtarzać, Modulekiedy dzwonisz Module.method(x). Biorąc powyższy przykładowy wykaz funkcji, dlaczego muszę ciągle powtarzać List? Powinien wiedzieć, że jest to Listi nie chcę wywoływać tej Navigation.map()funkcji! Korzystanie ze x.map()składni powoduje, że jest ona SUCHA i nadal jednoznaczna.

I oczywiście ma to zalety w porównaniu z metodą umieszczania wszystkiego w globalnej przestrzeni nazw . To nie jest tak, że obecny sposób nie jest w stanie zrobić rzeczy. Jest to nawet dość terse ( len(lst)), ponieważ nic nie ma przestrzeni nazw! Rozumiem zalety korzystania z funkcji (zachowanie domyślne itp.) W stosunku do metod, ale nadal mi się to nie podoba.

To jest po prostu bałagan. A w dużych projektach bałagan jest twoim największym wrogiem.

Brak homoikoniczności .

Python musiał poczekać, aż 3.x doda słowo kluczowe „z”. W każdym języku homoikonicznym można go trywialnie dodać do biblioteki.

Większość innych problemów, które widziałem w odpowiedziach, należą do jednego z 3 rodzajów:

1) Rzeczy, które można naprawić za pomocą oprzyrządowania (np. Płatki pyłu) 2) Szczegóły implementacji (GIL, wydajność) 3) Rzeczy, które można naprawić za pomocą standardów kodowania (tj. Cechy, których ludzie nie chcieliby, aby ich nie było)

# 2 nie jest problemem z językiem, IMO # 1 i # 3 nie są poważnymi problemami.

Python jest moim ulubionym językiem, ponieważ jest bardzo ekspresyjny, ale wciąż powstrzymuje cię od popełniania zbyt wielu błędów. Nadal mam kilka rzeczy, które mnie denerwują:

• Brak prawdziwych anonimowych funkcji. Lambda może być używana do funkcji pojedynczej instrukcji, a withinstrukcja może być używana do wielu rzeczy, w których użyjesz bloku kodu w Rubim. Ale w niektórych sytuacjach sprawia, że ​​rzeczy są nieco bardziej niezgrabne, niż musiałyby być. (Daleko od tak niezdarnego, jak by to było w Javie, ale nadal ...)

• Pewne zamieszanie w relacji między modułami i plikami. Uruchamianie „python foo.py” z wiersza poleceń różni się od „import foo”. Względny import w Pythonie 2.x może również powodować problemy. Mimo to moduły Pythona są o wiele lepsze niż odpowiednie funkcje C, C ++ i Ruby.

• Jawne self. Mimo że rozumiem niektóre z tego przyczyn i chociaż codziennie używam Pythona, często popełniam błąd, zapominając o tym. Innym problemem jest to, że tworzenie klasy z modułu staje się nieco nudne. Jawne ja wiąże się z ograniczonym zasięgiem, na który narzekali inni. Najmniejszy zakres w Pythonie to zakres funkcji. Jeśli utrzymujesz swoje funkcje na małym poziomie, tak jak powinieneś, nie jest to problem sam w sobie, a IMO często daje czystszy kod.

• Niektóre funkcje globalne, takie jak len, że można oczekiwać, że będzie to metoda (która faktycznie jest za kulisami).

• Znaczące wcięcie. Nie sam pomysł, który moim zdaniem jest świetny, ale ponieważ jest to jedyna rzecz, która powstrzymuje tylu ludzi przed wypróbowaniem Pythona, być może lepiej byłoby dla Pythona z niektórymi (opcjonalnymi) symbolami początku / końca. Ignorując tych ludzi, mógłbym całkowicie żyć z wymuszonym rozmiarem wcięcia.

• Że nie jest to wbudowany język przeglądarek internetowych, a nie JavaScript.

Spośród tych skarg to tylko pierwsza, na tyle mi zależy, że myślę, że należy ją dodać do języka. Inne są raczej niewielkie, z wyjątkiem ostatniego, co byłoby wspaniałe, gdyby tak się stało!

Python nie jest w pełni dojrzały: język Python 3.2 ma w tej chwili problemy ze zgodnością z większością obecnie dystrybuowanych pakietów (zazwyczaj są one kompatybilne z Pythonem 2.5). Jest to duża wada, która obecnie wymaga większego wysiłku programistycznego (znajdź potrzebny pakiet, sprawdź kompatybilność; zważ, wybierając niezbyt dobry pakiet, który może być bardziej kompatybilny; weź najlepszą wersję, zaktualizuj ją do wersji 3.2, co może zająć kilka dni; następnie zacznij robić coś pożytecznego).

Prawdopodobnie w połowie 2012 roku będzie to mniej mankamentem.

Zauważ, że chyba zostałem oceniony przez jednego z fanów-fanów. Podczas dyskusji programistów nasz zespół programistów wysokiego szczebla doszedł jednak do tego samego wniosku.

Dojrzałość w jednym głównym znaczeniu oznacza, że ​​zespół może korzystać z tej technologii i bardzo szybko działać bez ukrytych zagrożeń (w tym problemów ze zgodnością). Pakiety Python innych firm i wiele aplikacji nie działa w wersji 3.2 dla większości dzisiejszych pakietów. Powoduje to więcej pracy związanej z integracją, testowaniem, ponownym wdrażaniem samej technologii zamiast rozwiązywania danego problemu == mniej dojrzałej technologii.

Aktualizacja z czerwca 2013 r .: Python 3 nadal ma problemy z dojrzałością. Co jakiś czas członek zespołu wspomina o potrzebnym pakiecie, a następnie mówi „z wyjątkiem tylko wersji 2.6” (w niektórych przypadkach wdrożyłem obejście za pośrednictwem gniazda localhost, aby używać pakietu tylko w wersji 2.6 z wersją 2.6 i resztą nasze narzędzia pozostają w wersji 3.2). Nawet MoinMoin, wiki o czystym pythonie, nie jest napisane w Pythonie 3.

Zakres Pythona jest poważnie uszkodzony, co sprawia, że ​​programowanie obiektowe w Pythonie jest bardzo niewygodne.

Moje obawy dotyczące Pythona:

• Przykręcone OOP (patrz @ mipadi w celu uzyskania szczegółowych informacji na ten temat)
• Zepsuta implementacja lambd
• Problemy z zakresem
• Brak trwałych kolekcji w standardowej bibliotece
• Słaba podatność na osadzone DSL

Modyfikatory dostępu w Pythonie nie są egzekwowalne - utrudnia pisanie dobrze ustrukturyzowanego, zmodularyzowanego kodu.

Przypuszczam, że jest to część zepsutego ustalania zasięgu @ Masona - ogólnie duży problem z tym językiem. W przypadku kodu, który powinien być czytelny, wydaje się dość trudne do określenia, co może i powinno być w zakresie i jaką wartość będzie w danym momencie - obecnie myślę o przejściu z języka Python z powodu tych wad .

To, że „wszyscy zgadzamy się na dorosłych” nie oznacza, że ​​nie popełniamy błędów i nie pracujemy lepiej w ramach silnej struktury, szczególnie podczas pracy nad złożonymi projektami - wcięcia i bezsensowne podkreślenia nie wydają się wystarczające .

1. Wydajność nie jest dobra, ale poprawia się z pypy,
2. GIL zapobiega użyciu wątków w celu przyspieszenia kodu (chociaż jest to zwykle przedwczesna optymalizacja),
3. Przydaje się tylko do programowania aplikacji,

Ale ma kilka wspaniałych funkcji odkupienia:

1. Jest idealny dla RAD,
2. Łatwo jest połączyć się z C (i aby C mógł osadzić interpreter Pythona),
3. Jest bardzo czytelny,
4. Łatwo się nauczyć,
5. Jest dobrze udokumentowany,
6. Baterie są naprawdę włączone, standardowa biblioteka jest ogromna, a pypi zawiera moduły do ​​praktycznie wszystkiego,
7. Ma zdrową społeczność.

Jestem zwolennikiem Pythona, a pierwszą wadą, która przychodzi mi na myśl, jest to, że komentując takie zdanie if myTest():, musisz zmienić wcięcie całego wykonanego bloku, którego nie musiałbyś robić w C lub Javie. W rzeczywistości w pythonie zamiast komentowania klauzuli if zamiast tego zacząłem komentować w ten sposób: `if True: #myTest (), więc nie będę musiał zmieniać następującego bloku kodu. Ponieważ Java i C nie polegają na wcięciach, komentowanie instrukcji jest łatwiejsze w C i Javie.

Wysyłka wielokrotna nie integruje się dobrze z ustalonym systemem pojedynczej wysyłki i nie jest bardzo wydajna.

Ładowanie dynamiczne jest ogromnym problemem w równoległych systemach plików, w których semantyka podobna do POSIX prowadzi do katastrofalnych spowolnień w operacjach intensywnie wykorzystujących metadane. Mam kolegów, którzy spalili ćwierć miliona godzin pracy po prostu ładując Pythona (z numpy, mpi4py, petsc4py i innymi modułami rozszerzeń) na rdzeniach 65k. (Symulacja przyniosła znaczące nowe wyniki naukowe, więc było warto, ale jest to problem, gdy pali się więcej niż baryłkę ropy, aby załadować Pythona raz.) Brak możliwości statycznego połączenia zmusił nas do podjęcia wielkich skręceń, aby uzyskać rozsądne czasy ładowania w skali, w tym łatanie libc-rtld, aby umożliwić dostęp do dlopenzbiorowego systemu plików.

• spora część bardzo popularnych bibliotek i oprogramowania innych firm, które są szeroko stosowane, nie są pytoniczne. Kilka przykładów: soaplib, openerp, reportlab. Krytyka jest poza zakresem, jest tam, jest powszechnie używana, ale powoduje zamieszanie w kulturze Pythona (szkodzi motto, które mówi: „Powinien być jeden - a najlepiej tylko jeden - oczywisty sposób”). Wydaje się, że znane sukcesy w Pythonie (takie jak django lub trac) są wyjątkiem.
• potencjalnie nieograniczona głębokość abstrakcji instancji, klasy i metaklasy jest koncepcyjnie piękna i wyjątkowa. Ale aby go opanować, musisz dokładnie znać interpretera (w jakiej kolejności interpretowany jest kod python itp.). Nie jest powszechnie znany i używany (lub używany poprawnie), podczas gdy podobna czarna magia, taka jak generyczne C #, która jest koncepcyjnie bardziej skomplikowana (IMHO), wydaje się bardziej znana i stosowana proporcjonalnie.
• aby dobrze zrozumieć model pamięci i wątków, musisz mieć duże doświadczenie z Pythonem, ponieważ nie ma obszernej specyfikacji. Po prostu wiesz, co działa, może dlatego, że czytasz źródła tłumacza lub doświadczasz dziwactw i odkryłeś, jak je naprawić. Na przykład istnieją tylko mocne lub słabe referencje, a nie miękkie i fantomowe referencje java. Java ma wątek do wyrzucania elementów bezużytecznych, podczas gdy nie ma formalnej odpowiedzi na temat tego, kiedy odbywa się to w Pythonie; możesz po prostu zauważyć, że wyrzucanie elementów bezużytecznych nie ma miejsca, jeśli nie jest wykonywany kod Pythona, i wyciągnij wniosek, że prawdopodobnie dzieje się to czasami podczas próby przydzielenia pamięci. Może to być trudne, gdy nie wiesz, dlaczego zablokowany zasób nie został zwolniony (moje doświadczenie na ten temat to mod_python we freeswitchu).

W każdym razie python jest moim głównym językiem od 4 lat. Bycie fanboyem, elitą lub monomanią nie jest częścią kultury pytona.

• Dziwne OOP:
  • len(s)poprzez __len__(self)i inne „metody specjalne”
  • dodatkowe metody specjalne, które można uzyskać z innych metod specjalnych ( __add__oraz __iadd__dla +i +=)
  • self jako pierwszy parametr metody
  • możesz zapomnieć o wywołaniu konstruktora klasy podstawowej
  • brak modyfikatorów dostępu (prywatny, chroniony ...)
• brak stałych definicji
• brak niezmienności dla typów niestandardowych
• GIL
• słaba wydajność, która prowadzi do połączenia Pythona i C oraz problemy z kompilacjami (szukanie bibliotek C, zależności platformy ...)
• zła dokumentacja, szczególnie w bibliotekach stron trzecich
• niekompatybilność między Python 2.x a 3.x
• słabe narzędzia do analizy kodu (w porównaniu do tego, co jest oferowane dla języków o typie statycznym, takich jak Java lub C #)

„Niezmienność” nie jest dokładnie jego mocną stroną. Liczby, krotki i łańcuchy AFAIK są niezmienne, wszystko inne (tj. Obiekty) można modyfikować. Porównaj to z funkcjonalnymi językami, takimi jak Erlang lub Haskell, w których wszystko jest niezmienne (przynajmniej domyślnie).

Jednak niezmienność naprawdę świeci dzięki współbieżności *, która również nie jest mocną stroną Pythona, więc przynajmniej jest konsekwencją.

(* = Dla nitpickerów: mam na myśli współbieżność, która jest przynajmniej częściowo równoległa. Wydaje mi się, że Python jest w porządku z współbieżnością „jednowątkową”, w której niezmienność nie jest tak ważna. (Tak, miłośnicy FP, wiem, że niezmienność jest świetnie nawet bez współbieżności.))

Chciałbym mieć wyraźnie równoległe konstrukcje. Częściej niż nie, kiedy piszę listę ze zrozumieniem

[ f(x) for x in lots_of_sx ]

Nie obchodzi mnie kolejność, w jakiej elementy będą przetwarzane. Czasami nawet mnie nie obchodzi, w jakiej kolejności są zwracane.

Nawet jeśli CPython nie może zrobić tego dobrze, gdy mój f jest czystym Pythonem, takie zachowanie można zdefiniować dla innych implementacji.

Python nie ma optymalizacji wywołania ogona, głównie z powodów filozoficznych . Oznacza to, że rekurencja na dużych strukturach może kosztować pamięć O (n) (z powodu niepotrzebnego stosu, który jest utrzymywany) i będzie wymagać przepisania rekurencji jako pętli w celu uzyskania pamięci O (1).