Python i type hints

Cześć, jakiś czas temu zacząłem sobie prywatnie dłubać projekt w pythonie. Jako że zależało mi bardziej na poznaniu samego pythona niż konkretnych frameworków wybrałem flaska bo choć nieidealny to daje dużo wolności. Używam też wzorców taktycznych DDD. I teraz pytanie praktyczne - czy używać type hints? Może tylko w domenowej części, a może wcale? Nie wiem jak do tego podchodzi community, bo patrząc na niektóre snippety kodu to ekstrawagancją jest tworzenie obiektów, a co dopiero podpowiedzi związane z ich tożsamością (zauważam tendencję do pchania wszędzie dictionary). Wiem że przez język te hinty i tak są ignorowane jednak narzędzia takie jak pyright po pierwsze istnieją a po drugie raczej ułatwiają życie - zwłaszcza gdy projekt się rozrasta.

Jest jakieś python way? Czy każdy powinien robić jak uważa? Jak robi się najczęściej, a jakie są utarte best practices (źródełko?)?

Bez type hints poprawny refactoring (np. zmiana nazw metod) nie jest możliwy.

Dlatego uważam, że wiele bólu głowy sobie oszczędzisz wybierając język, który "wymusza type hints". Czyli np. C#, albo Java.
W Pythonie musiałbyś pilnować się oraz resztę zespołu. Piekło perfekcjonisty...

@Spine: Z jednej strony tak, ale z drugiej język który daje tego typu dowolność pozwala na zastosowanie odpowiedniej ilości pragmatyzmu. Pytanie, jak duża ona jest i w jakim zakresie? Osobiście wsadziłem te typy prawie wszędzie. Nie jestem jednak przekonany że to dobrze. Stąd jestem ciekawy co wypracowali przez lata pytoniści :) Sam zaczynałem w silnie typowanych językach i zdaję sobie sprawę z zalet typów. Niewiele zalet z kolei widzę w ich braku. Chyba pośrednio to miałem na myśli.

Oczywiście ładowanie typingu wszędzie gdzie popadnie zrobi więcej szkody niż pożytku. Jak sam zauważyłeś jest to opcjonalne i każdy robi to po swojemu. Grunt to zachować pewien zdrowy rozsądek. Kiedyś typingu nie było i ludzie nadal pisali czytelny kod zawierając najpotrzebniejsze informacje w doc stringach :P

Moim zdaniem w jakimkolwiek większym kodzie to jest absolutnie konieczne żeby zachować resztki zdrowego rozsądku. Inaczej nawet trywialne operacje w stylu rename czy find usages stają się ciężkim zadaniem.

@orchowskia: wszyscy wiemy, że się powinno, ale nie zawsze wychodzi. Lata przyzwyczajeń robią swoje.
Wielokrotnie spotkałem się z kodem, jak i zdaniem programistów, że przynajmniej warto oznaczyć typy argumentów metod i typ zwracany. A w środku to już na luzie :)

Nawet Java ma już swoje var...

@niedowiary myslisz dwie zupełnie niepowiązane rzeczy. Czym innym jest inferencja typów (jak w językach funkcyjnych czy nawet ten var w Javie) a zupełnie czym innym jest dynmiczne typowanie. Inferencja sprawia tylko że ty nie musisz specyfikować typu, bo kompilator może go sobie "wywnioskować". W Pythonie nic takiego nie ma miejsca.

Np. nie możesz czegoś takiego zrobić:

        var x = "test";
        x.whatever();

Bo inferencja typów wie że x jest typu String i to się nie skompiluje. W Pythonie to się wywali dopiero w runtime.

@orchowskia:

Jeżeli nie jesteś przyspawany do flaska to może to Cię zainteresuje: https://fastapi.tiangolo.com/python-types/

Czy mówiąc o DDD umiesz:
-pisać czytelny kod
-pisać testowalny kod
-umiesz projektować kod obiektowo/funkcyjnie
-znasz wzorce projektowe

Po pierwsze naucz się podstaw i bardziej skupiłbym się (po opanowaniu podstaw) na opanowaniu automatycznego diploymentu na CI/CD (Gitlab, Github action) oraz generowaniu dokumentacji (Sphinx) oraz dużo pokazywania kodu innym. Tego brakuje. Na DDD i inne patologie przyjdzie czas. Na razie bez solidnych podstaw zrozumienia jak to działa polecam zapoznać się z książkami:
Fluent Python - Luciano Ramalho
Beazley D. - Python. Receptury.

Jak ktoś mi wyskakuje z tą chorobą DDD-odozą pospolitą w pythonie to mi się nie dobrze robi. To nie działa. Nasłuchał się Sławomira S. i teraz myśli że jak to zastosuje to zadziała.
Nie, nie zadziała.

Czy po prostu rzuciłeś się na DDD bo to modne?
Pod pojęciem DDD rozumiesz Dawaj Dawaj Diploj czy Deadline Driver Development?

Python może w wielu miejscach jest gentlemana agreement ale z praktycznego doświadczenia:

• Type hinty w docstringach lub typowaniu poprzez przykład dając dobry kod, pokazujemy zespołowi, że warto
• I/lub narzucamy na poziomie projektu i konfigurujemy to na poziomie ci/CD aby każdy tego przestrzegał

Czasami te type hinty są pokraczne, ale nie widzę zbytnio argumentu przeciwko. To tak jak nie używać typescripta programując w jsie.

sa plusy tego ale jeszcze nie pracowalem w projekcie w ktorym korzystano z tego niestety. malo ludzi z tego korzysta (przynajmniej pracujac w Django)