W takim przypadku musisz to definiować lub dociągać, a w Pythonie masz to wbudowane i po zainstalowaniu interpretera masz te mechanizmy od razu
Ale co... bo wydaje mi się, że pokazałem iż "kaczkotypy" masz praktycznie identycznie wyglądające w Darcie.
Typ variant działa tak samo w Dart i Python, praktycznie jedyna różnica jest że w Dart trzeba jawnie napisać przy deklaracji zmiennej dynamic. Poza tym - nie widzę różnic. Więc co takiego masz OOTB w Pajtonie/jakie mechanizmy trzeba dodawać? O czym piszesz? Bo naprawdę - nie rozumiem. Chyba, że chodzi o jakieś biblioteki standardowe - ale to nie ma nic wspólnego z typami/brakiem typów i uciekamy w rozważania czy Pyton jest spoko czy bleeeee.
Z mojego i tylko mojego punktu widzenia + doświadczenia, takie sytuacje, że podstawiasz str pod zmienną, która operuje na int i masz rzucany wyjątek są bardzo rzadkie.
OK, zdarza się rzadko, zwłaszcza jak jesteś ogarnięty i wiesz, co robisz, masz porządek w kodzie, przemyślane struktury danych itp. Ale potem do projektu przyjdzie jakiś głupi świeżak, który nie ma pojęcia co i jak się robi i namiesza. Wiem, wiem - są testy, podpowiedzi IDE itp, - ale można takie ryzyko wyeliminować poprzez stosowanie typów. Poza tym nie przemawia do mnie argument na ogól to działa. Jakbym powiedział że regularnie w klubie wyrywam laski, biorę do hotelu i się bawimy bez zabezpieczeń, ale póki co nie złapałem żadnego grzyba ani AIDS'a to byś raczej uznał, że jestem nieodpowiedzialny. Albo od 20 lat jeżdze po paru piwkach, nigdy mnie nie złapali, więc nie wiem o co jest całe zamieszanie - czy takie zachowanie pochwalasz? A tutaj wydaje mi się, że zastosowałeś taką samą logikę - rzadko wywala błąd, więc nie widzę sensu korzystania z zabezpieczeń, które mi oferuje język typowany.
Pamiętam, że na etapie nauki C udawało mi się napisać takie programy, które się kompilowały, a wywalały na etapie wykonywania.
Oczywiście, zawsze jest ryzyko. Wracając do analogii z poprzedniego akapitu - stosowanie prezerwatywy nie daje 100% pewności, tak samo jak pasy bezpieczeńśtwa i poduszki nie gwarantują, że z każdej kolizji wyjdziesz bez szwanku. ALE znacząco zwiększają one szanse, że będzie OK. Tak samo z typami - wiadomo, że da się napisać coś, co się kompiluje, ale potem rzuci wyjątkiem czy jakimś segfault'em, ale dzięki stosowaniu typów takie ryzyko jest znacznie mniejsze.
Porównanie do malucha jest efektowne, ale chybione. Python bez typów to nie maluch, tylko lekki samochód sportowy bez elektronicznych asystentów.
Chyba się nie zrozumieliśmy. Nie porównywałem Pajtona do malucha, ale odniosłem się do Twojego argumentu że Pisałem kiedyś backend web aplikacji największego banku w Polsce w pythonie bez typów i jakoś dawało radę. i chodziło mi o pokazanie błędu w takim założeniu. Oczywiście, że tak, jak napisał @lion137 Na upartego wszystko napiszesz w dowolnym sensownym języku i tak samo możesz wkrętarką wbijać gwoździe. Ale lepiej wziąć do tego młotek. To, że kiedyś coś się dało zrobić nie oznacza, że to jest najlepsza opcja. I o to mi chodziło o jechanie po pythonie, tylko o pokazanie błedu w takiej logice. Bo dało się mieszkać w lepiance na wsi, ale mile się mieszka w apartamencie.
Nadmierne typowanie w Pythonie drastycznie zwiększa Cognitive Load. Zamiast skupiać się na logice przelewu, programista spędza 30% czasu na walce z typami. Problem polega na tym, że próbujesz zmienić Pythona w gorszą wersję Javy
Nie chce zmieniać pythona, całe zamieszanie zaczęło się od tego, że ktoś (chyba @lion137 ) napisał,że typy mu przeszkadzają. I z tym się nie zgodziłem. Chyba żyjemy w innych światach, bo nie wyobrażam sobie jak można 30% czasu poświęcić na zastanawianie się, czy coś będzie int czy double. Nie mówię, że kłamiesz albo piszesz głupoty, skoro tyle czasu Ci to zajmuję - przyjmuję to do wiadomości i szanuję (serio - nie odbierz tego że Cie wyśmiewam albo po Tobie jadę). Dla mnie po prostu ustalenie tego, jakie dane będę przetwarzać jest częścią wymyślania logiki aplikacji. To trochę jak z TDD - osoby z tego korzystające mówią, że to odwraca sposób tworzenia. Najpierw myślisz o testach, zastanawiasz się jak to ma działać, ustalasz warunki brzegowe i tworzysz testy, a potem dopiero bierzesz się za implementację. I tutaj jest podobnie. OK, jeśli dostajesz jakieś losowe dane z tyłka i potem musisz na bieżąco kombinować jak do nich dobrać typy to rzeczywiście może być problem, ale jeśli wyjdziesz z innego założenia - najpierw zastanowisz się CO chcesz przetwarzać i do tego dopasujesz struktury danych, to potem nie powinno być niespodzianek. Zresztą nawet przykład podany przez @Pyxis czyli przetwarzanie liczb w różnych formatach - tak naprawdę to i tak możesz mieć 2-3 (a moze 3-4) sposoby ich zapisu. Jeśli pobierasz dane w jakimś JSON to możęsz mieć 13, "13" albo 13.0. I te wartości można przetworzyć na liczbę w formacie, który Ci pasuje. Można to ogarnąć dosłownie 2-3 linijkową lambdą albo jakąś funkcją pomocniczą. Jeśli masz wykonać obliczenia na takich danycn, ale zamiast (w jakikolwiek sposób zapisanego) numerka dostaniesz "Litfo ojczyzno moya" to i tak się apka wychrzani/wywali jakiś wyjątek, albo przekonwertuje (pozdrawiam serdecznie JS :D ) na jakąś wartość z czapy. Także nie widzę tutaj za bardzo zysku, raczej możliwość błedów i losowych wartości.
Typy sprawdzają tylko strukturę danych, a testy sprawdzają ich poprawność. Tylko test powie Ci, czy ten Decimal nie jest ujemny po naliczeniu prowizji. Nawet w najbardziej typowanych językach świata (Haskell, Rust) i tak musisz pisać te same testy logiczne, które pisaliśmy w banku. Typy nie zwalniają z myślenia, one tylko dają złudne poczucie bezpieczeństwa.
OK, ale nie mieszajmy dwóch rzeczy. To, że w zmiennej która ma być int masz liczbę całkowitą to jest kwestia... nazwijmy to "merytoryczna". A to, czy rabat albo saldo może być ujemne to już logika biznesowa. To tak samo jak z obsługą narzędzia - jak masz np. szlifierkę kątową to podczas jej używania powinno się przestrzegać pewnych zasad: odpowiednio trzymać, mieć okulary ochronne, nie dotykać tarczy jak jest wpięta do zasilania itp. I to jest odpowiednik pilnowania typów. Ale możesz poprawnie trzymając piłę rzucić się na kolegę i mu obciąć rękę. To są dwie osobne rzeczy. Tak samo tutaj - pilnowanie typów oznacza jedynie, że masz pewność, że w miejscu przeznaczonym na liczbę masz liczbę a nie tekst. Ale co z tą liczbą zrobisz to już osobna kwestia, której (tutaj pełna zgoda) kompilator za Ciebie nie ogarnie i zgadzam się - nadal musisz myślec nad tym co i jak aplikacja robi.
