•  

    Dlaczego python nie chce wprowadzić możliwości statycznego typowania zmiennych?

    Czytam sobie PEPy na temat podpowiadania typów zmiennych i jest tam napisane, że python pozostanie wyłącznie dynamicznie typowany. I tak się zastanawiam, dlaczego autorzy nie chcą dać programistom możliwości wyboru.

    Ostatnio dużo czytam kodu dla deep learning pisanego przez duże firmy jak Facebook, Microsoft, Amazon i prawie zawsze zmienna służy do przechowywania tylko konkretnego rodzaju danych. Więc bez problemu mogłaby mieć statyczne typowanie. Pewnie przyspieszyłoby to odrobinę wykonywanie, gdyby kompilator mógł z tego skorzystać.

    Skąd u twórców pythona tak silna niechęć do wprowadzenia takiego rozwiązania?

    #python

    •  

      @ProfesorBigos: bo w pythonie sie pisze pod interfejs

    •  

      @ProfesorBigos: a czemu nie uzyjesz javy jak ci sie niepodoba? dla mnie jak jezyk ma za duzo paradygmatow jak np. c++ to mozna dostac downa

    •  

      Największą bolączką typowania w Pythonie jest obecnie przywiązanie do istniejącego już syntaxu zamiast stworzenia nowego, specjalnie na potrzeby typowania, po prostu wygląda i pisze się to źle

    •  

      @Maka_Albarn: Bo python jest obecnie standardem w deep learning.

    •  

      @ProfesorBigos: Zagadka.

      a = []
      a.append(a)

      Jakiego typu powinna być zmienna a?

      for i in a:

      Jakie typu powinna być zmienna i?

    •  

      @Lunatik: Jak dopisałem podpowiedzi typów w definicjach funkcji w moim skrypcie, to czytelność na pewno się nie poprawiła. Tak samo dataclasses, niby przydatne, ale wyglądają okropnie w kodzie.

    •  

      @legolass: Dla takich dziwnych użyć byłoby właśnie dynamiczne typowanie albo:

      a: List[Any] = []

      i wtedy kompilator przyjąłby

      for i: Any in a: List[Any]

    •  

      @legolass: W obu przypadkach powiedziałbym, że 'list'. Przynajmniej nie widzę najmniejszego powodu, aby było inaczej.

    •  

      @venomik: Chodziło mi o to jakiego typu jest element listy

      @ProfesorBigos: Dodając typ Any za dużo nie zyskujesz, bo dalej w sporej części kodu możesz nie wiedzieć o jaki typ chodzi.

      A jak chcesz się pobawić w typowanego pythona to jest http://mypy-lang.org/

    •  

      @legolass: Podałeś dość ekstremalny przykład, który w wielu innych językach w ogóle nie mógłby być napisany. Więc to raczej słaby argument.

      MyPy jest całkiem fajne, ale to jest tylko sprawdzanie i podpowiadanie typów, a nie typowanie zmiennych.

    •  

      @ProfesorBigos: bo wtedy to nie byłby python, jest wiele wspaniałych języków programowania ze statycznym typowaniem

    •  

      @ProfesorBigos: Ten przykład powinien działać we wszystkich językach dynamicznie typowanych i to jest właśnie ich zaleta. Trochę bawiłem się inferencją typów i to właśnie dla takich "słabych argumentów" są największe trudności.

      Jeśli mielibyśmy statyczne typowanie to sporym problemem byłoby również rzutowanie takich obiektów. Jeśli miałbyś np funkcję która przyjmuje typ Any to mając int i =1 i wywołując taką funkcję musiałbyś tego inta opakować w dodatkowy typ, a później go zostawić, albo ponownie odpakować.

      W wyniku mogłoby się okazać, że w kółko trzeba te obiekty pakować i rozpakowywać, co samo w sobie spowolniło by działanie aplikacji. Oczywiście można by to jakoś ograniczyć, żeby uniknąć takiej sytuacji, ale wtedy zmieniamy język w coś podobnego do pythona.

      Kolejnym problemem jest monkeypatching. Na etapie statycznego typowania tak na prawdę kompilator nie wiedziałby czy metoda w klasie/module jest tą metodą, która będzie wywołana czy nie. Żeby się dowiedzieć trzeba wykonać program, a przecież nie o to chodzi.

      Jeszcze jedna trudność to dynamicznie tworzone typy. Python pozwala stworzyć Ci typ w trakcie działania programu. Statyczne typowanie w takiej sytuacji po raz kolejny okazałoby się niewystarczające.

      Co więcej opisane przeze mnie przypadki nie są moim wymysłem teoretycznym, ale właśnie ciekawymi, czasami przydatnymi rozwiązaniami, dlatego nie można ich zablokować.

      Podsumowując takie statyczne typowanie przynosiłoby wymierne rezultaty w ściśle określonych przypadkach. W pozostałych zysk byłby zerowy, albo nawet program byłby mniej wydajny. Dodatkowo typowanie spada na programistę, a to powoduje wolniejsze prototypowanie, konieczność kompilowalności całego programu (kto nigdy nie patrzył czy kod wywali się na niezaimplementowanej funkcji, czy wcześniej) i ewentualne ograniczenie możliwości języka.

    •  

      @legolass: Ja przecież nie pytam o ograniczenie języka do statycznego typowania, tylko rozszerzenie go o taką możliwość by dać programistom więcej swobody. Tak jak napisałem na początku, w kodzie pisanym przez programistów z takich firm jak FB czy MS prawie nie występują sytuacje o jakich wspominasz.

      Jeśli miałbyś np funkcję która przyjmuje typ Any to mając int i =1 i wywołując taką funkcję musiałbyś tego inta opakować w dodatkowy typ, a później go zostawić, albo ponownie odpakować.

      @legolass: Chyba odwrotnie. Gdybyś miał funkcję przyjmującą int i chciałbyś użyć ją na zmiennej Any, to musiałbyś castować. Ale w pythonie jest zasada "Explicit is better than implicit", więc nie widzę problemu.

    •  

      Czytam sobie PEPy na temat podpowiadania typów zmiennych i jest tam napisane, że python pozostanie wyłącznie dynamicznie typowany. I tak się zastanawiam, dlaczego autorzy nie chcą dać programistom możliwości wyboru.

      @ProfesorBigos: No właśnie dają wybór. Type hints sprawiają, że i wilk jest syty i owca cała. Nie ma możliwości żeby nagle wymusili statyczne typowanie, to by oznaczało powstanie nowego języka.

      Natomiast zgadzam się z Tobą, że typowanie zmiennych jako takie ma sens. Dlatego w kodzie pythonowym, który piszę używam type hintsów i mypy.

    •  

      @mathix: Właśnie sobie poczytałem dyskusje na ten temat i podzielam jedną z opinii, że type hints dużo lepiej wyglądają w docstringu zamiast w sygnaturze funkcji. Bo czasami robi się taki pierdolnik jak na screenie

      źródło: Przechwytywanie.PNG

    •  

      @ProfesorBigos: Zależy od API. Języki typu C#, Java, Scala itd. sobie z tym radzą. Po prostu w pythonie się przyjęło robić takie metody.

      Patrząc na sukces TypeScripta ja jestem pozytywnie nastawiony do type hintingu. IMO języki bez typowania niestety powodują powstawanie ciężkich w utrzymaniu projektów.

    •  

      @mathix: Mnie się osobiście spodobał Rust. Scala ma ponoć ogromny potencjał. Python mógłby zapożyczyć wiele pozytywnych rozwiązań od innych języków, jak chociażby jawne definiowanie czy coś jest mutable czy immutable albo rozróżnienie przekazywania wartości i referencji foo(bar) vs foo(@bar).

    •  

      @ProfesorBigos: To drugie to akurat domena niskopoziomowych języków jak Rust czy C++.

    •  

      @legolass:

      a = []
      a.append(a)
      Jakiego typu powinna być zmienna a?
      for i in a:
      Jakie typu powinna być zmienna i?


      czemu powinna?
      przyszedł śmierdziel i już mu się nie podoba, że nie może zdefiniować sobie int32.

Gorące dyskusje ostatnie 12h