@piordonek: przejście z C do Python to dla mnie mindfuck był - skąd ja mam wiedzieć co ta funkcja chce? Int, string, class? Używać isinstance() czy walić .method i łapać exception?
@Boska_Klaudia: ogólnie to czasem dużo dają docstringi, ale wychodzę z założenia że docstringi to największe kłamstwo, bo często się spotykałem z sytuacją że metody robiły co innego niż było napisane (ʘ‿ʘ)
@Arogancky: ja doszedłem do wniosku że najlepiej to operować na tym co się dostało i sprawdzać AttributeError czy jak się nazywa ten exception jak attribute w object nie ma
@piordonek: jeśli projekt zamykasz w miesiąc max 3 to typy są niepotrzebne. Jesli natomiast masz system który na być rozwijany i utrzymywany latami to tylko ścisłe typy, najlepiej z null safety
@zibizz1: To są centralki telefoniczne stworzone przez Ericssona i oprogramowane w Erlangu, które w testach wykazały 99.9999999% niezawodności, a w 20-letnim stażu pracy ~99.999% niezawodności.
@zibizz1: Statycznych typów nie ma, jest dynamiczne typowany. Co więcej dodanie statycznych typów i utrzymanie podstawowych założeń języka jest praktycznie niemożliwe. Oczywiście jest językiem silnie typowanym, ale dynamicznie.
@Hauleth: OK, ale jak często robi się deploy na tym AXD301, jak dużo użytkowników wrzuca tam swój input? Jaki związek ma uptime z ilością błędów w oprogramowaniu? Czy podmiana fragmentu kodu na taki z błędami możliwymi do wykrycia w trakcie kompilacji bez zatrzymywania programu to dowód że brak statycznych typów jest OK? Czy wywalenie się obsługi części danych podczas gdy reszta programu działa dowodzi że program działa bezbłędnie? Dlaczego społeczność zamierza
https://docs.python.org/3/library/typing.html
co jest fantastyczne biorąc pod uwagę założenia pythona, aleee ¯\_(ツ)_/¯
@Hauleth: Kto to jest?
@zibizz1: w #!$%@?, bo to obsługuje rzeczy jak internet czy połączenia telefoniczne.
Błędy (zwłaszcza dot. typów) z reguły powodują wyłożenie się programu, o ile nie są jakoś obsłużone. Wyłożenie się programu zmniejsza uptime.
Nie, ale jeśli wywala się nie