@Massad: napisałem przecież, że jeszcze nie zdarzyło się abym musiał. Python wcale nie ma monopolu na biblioteki, skąd się wzięło przekonanie że poza Pythonem nie ma innego świata? Pewnie nie będziesz mieć problemu aby wymienić przynajmniej 10 ważnych bibliotek, do których odpowiedników nie ma w kodzie natywnym.
A czy szybiej jest napisać w C++ i przepisać w C++ czy napisać w Pythonie i przepisać w C++?
@Massad: o wiele łatwiej przepisywać w obrębie tego samego języka, zwłaszcza że w C++ i innych językach statycznie typowanych masz dobre narzędzia do automatycznego refaktoringu a dla Pythona i języków dynamicznych nie. Poza tym w obrębie jednego języka możesz przepisywać po kawałku, co jest mniej ryzykowne niż big bang rewrite.
masz dobre narzędzia do automatycznego refaktoringu a dla Pythona i języków dynamicznych nie
@Krolik: Jak w C++ użyjesz void* to też nie ma refaktoringu. od dobrych kilku lat nie ma powodu aby kod nie był otypowany. w c++ wymusza to kompiler, a w pythonie można zrobić to za pomocą mypy na CI. Są dobre narzędzia do refacktoringu pythona. np biblioteka rope.
ponieść koszty napisania aplikacji lub jej dużych fragmentów drugi raz, bo na pewno nie przepiszesz Pythona do Rust/C++ 1:1 (bo w Rust/C++ niemal zawsze da się zrobić to samo lepiej i prościej).
Źródła jakieś? W sensie, że w Ruście czy C++ napiszesz coś "lepiej" i "prościej" (niż w Pythonie) - i dobrze, aby źródła definiowały czym jest to "lepiej" i "prościej". Masz doktorat, więc strzelam, że podeprzesz twierdzenie
Jak w C++ użyjesz void* to też nie ma refaktoringu
@Massad: od dobrej dekady nie ma powodu używać void* w C++.
@devopsiarz: Nie ma na ten temat bogatej literatury, bo to jest nowy język, ale wystarczy popatrzeć na dokumentację języka aby zobaczyć, że Rust posiada silniejsze i bogatsze mechanizmy abstrakcji niż Python. Trzy przykłady
@Massad: od dobrej dekady nie ma powodu używać void* w C++.
@Krolik: od dobrych 3 lat nie ma powodu aby nie używać typowania w Pythonie. Masz już Generic w module typing.
1. Automatyczne zwalnianie zasobów. To jest masa kodu, którego nie trzeba pisać w takim Rust (i w sumie C++ też), a który często w językach takich jak Java i Python zawiera błędy i który musisz napisać
@Krolik: rozumiem, że tytuły naukowe broni się za pomocą "wystarczy popatrzyć, aby zobaczyć..."? Bardzo to ciekawe. Nie, nie wystarczy, i cytując Ciebie, to pewnie wiesz na kim spoczywa ciężar dowodu [1].
1) I które konkretnie zasoby musisz zwalniać w Pythonie, bo GC tego nie ogarnie? Ale tak konkretnie i najlepiej na przykładzie kodu. Od razu spytam o Go (pomińmy defer - to jest kontrowersyjne) i Jave, bo pewnie tam też coś
@Krolik: no tak, bo w pythonie nie ma weakref. A nie czekaj. I może jeszcze mówisz, że smat pointery są odporne na cykle?
@Massad: cykle są problemem czysto teoretycznym. Przypadek brzegowy, który ani razu przez ostatnie kilka lat pracy z C++ i Rust nie przysporzył mi kłopotu. I co z tego że jest weakref - jak nie masz gwarancji kiedy GC go posprząta. Zasoby muszą być zwalnianie deterministycznie.
@devopsiarz: ok, zgoda, nie ma na ten temat dobrych badań, bo jest za wcześnie i generalnie bardzo trudno takowe badania przeprowadzić. Zresztą jak byś takie badania przeprowadził? Musiałbyś napisać duży projekt w jednym i drugim i porównać pod względem różnych metryk. Ale potem bardzo łatwo takie porównanie podważyć, bo np. ekipy różniły się poziomem doświadczenia. No i chciałbym zauważyć, że to jest wykop a nie periodyk naukowy. Każdy ma prawo
ok, zgoda, nie ma na ten temat dobrych badań, bo jest za wcześnie i generalnie bardzo trudno takowe badania przeprowadzić. Zresztą jak byś takie badania przeprowadził?
Zaraz, zaraz. Ja ich nie muszę przeprowadzać, bo i po co? ( ͡°͜ʖ͡°) To Ty wziąłeś sobie za cel porównywanie Pythona i Rusta i rozpowiadanie na forach jaki Rust jest genialny i zwięzły, a Python taki czy owaki, więc
Nie widzę tu aby click generował strukturę danych. Wygląda na bardzo ograniczone.
@Krolik: a czemu ma generowac strukturę danych jak robi CLI dla funkcji na podstawie jej argumentów?
3) To fakt i ja z tym akurat nie polemizuję.
@devopsiarz: mozecie moze powiedzieć co macie na myśli w tym kontekście? Ostatnio napisałem dość dużo kodu bazującego na adnotacjach typów i w zależności od tego zmieniających działanie w runtime.
@Massad: imho nie można porównywać jakiegoś silnego systemu typów wbudowanego w język, który jest restrykcyjnie sprawdzany np. przy kompilacji, do sprawdzania typów w języku dynamicznie typowanym takim jak Python za pomocą zewnętrznych narzędzi lub runtime. To są dwa różne światy.
Owszem, możesz type hintować i w runtime sobie sprawdzać typy na podstawie jakichś isinstance czy tego typu wynalazków, to może dużo pomóc w wyłapywaniu błędów związanym z typowaniem (porównując z
a czemu ma generowac strukturę danych jak robi CLI dla funkcji na podstawie jej argumentów?
@Massad: np. temu, że potem chcesz dorzucić alternatywnie konfigurowanie z pliku i zamiast dopisać kilka linii to musisz zrobić wszystko od nowa. Nie mówiąc o tym, że konfiguracja jako strktura jest wygodniejsza aby ją przekazywać gdzieś dalej. A tutaj co, jak będziesz mieć 20 paramtrów, to potem 20 paametrów będziesz przekazywał przez kilka poziomów wywołań funkcji?
Np. w moim projekcie pamięć i pliki nie muszą być zwalniane natychmiast
Problem polega na tym, że opierając się na GC, nie tylko nie będą zwalniane natychmiast, ale nie masz gwarancji, że w ogóle zostaną kiedykolwiek zwolnione. A takie deskryptory plików w domyślnej konfiguracji potrafią się bardzo szybko skończyć (bo domyślnie w wielu systemach jest ich tylko 1024 / proces).
@devopsiarz: tylko punkt 3 dotyczyl nidostepnosci typow w runtime. Pokazalem kilka przykladow, ze można dpawdzac annotacje typow w czasie wykonania programu.
Jezeli chodzi o silnosc typowania to w pythonie jest tak samo silna jak w C++ tylko sprawdzana w czasie wykonania, a nie kompilacji. Jak nie ma przeciazonego operatora to dana operacja nie zostanie wykonana.
Takim dorym porownaniem bylby kod w C++ ktory masowo wykorzystuje Template i iteratory. Tam tak samo.
są one zwalniane zaraz po zawołaniu close co używając context managera robi się automatycznie.
@Massad: no typ to jest takie samo słabe rozwiązanie jak try w javie. Po pierwsze użycie pliku masz wtedy przyczepione do zasięgu leksykalnego, po drugie musisz pamiętać o tym aby takowego kontekstu użyć lub zawołać ręcznie close. Przy czym ręczne zawołanie close może skończyć się tym że zostanie pominięte jesli poleci wyjątek. Czyli zarządzasz ręcznie a
Masz try ... final i zamkniesz zawsze. A jedyny przypadek wyczerpania deskryptorow miałem w c++, bo jednak był o jeden smart pointer za dużo. Od tego czasu pilnuje aby zamykać pliki jak tylko przestają być potrzebne.
I cały czas mówimy o bibliotece rozwiązującej problem, którego obecnie w ogóle nie jesteś w stanie nawet ugryźć w Pythonie, więc jak bardzo spartolona by nie była, to i tak jest to nieskończenie lepsza od tego co masz w Pythonie, bo w Pythonie nie masz na razie nic w tej kwestii.
#programista15k #programowanie #humorinformatykow #pracait #informatyk #takemybreathaway
źródło: comment_1656504201VfWeB9m2X3fecnyNdo5BHs.jpg
Pobierz@Krolik: czyli piszesz, że chcesz unikać pythona, bo jest wolny i zużywa za dużo zasobów więc będziesz wołać kod pythonowy?
@Massad: o wiele łatwiej przepisywać w obrębie tego samego języka, zwłaszcza że w C++ i innych językach statycznie typowanych masz dobre narzędzia do automatycznego refaktoringu a dla Pythona i języków dynamicznych nie. Poza tym w obrębie jednego języka możesz przepisywać po kawałku, co jest mniej ryzykowne niż big bang rewrite.
@Krolik: Jak w C++ użyjesz void* to też nie ma refaktoringu. od dobrych kilku lat nie ma powodu aby kod nie był otypowany. w c++ wymusza to kompiler, a w pythonie można zrobić to za pomocą mypy na CI.
Są dobre narzędzia do refacktoringu pythona. np biblioteka rope.
Źródła jakieś? W sensie, że w Ruście czy C++ napiszesz coś "lepiej" i "prościej" (niż w Pythonie) - i dobrze, aby źródła definiowały czym jest to "lepiej" i "prościej". Masz doktorat, więc strzelam, że podeprzesz twierdzenie
@Massad: od dobrej dekady nie ma powodu używać void* w C++.
@devopsiarz: Nie ma na ten temat bogatej literatury, bo to jest nowy język, ale wystarczy popatrzeć na dokumentację języka aby zobaczyć, że Rust posiada silniejsze i bogatsze mechanizmy abstrakcji niż Python. Trzy przykłady
@Krolik: od dobrych 3 lat nie ma powodu aby nie używać typowania w Pythonie. Masz już Generic w module
typing.1) I które konkretnie zasoby musisz zwalniać w Pythonie, bo GC tego nie ogarnie? Ale tak konkretnie i najlepiej na przykładzie kodu. Od razu spytam o Go (pomińmy defer - to jest kontrowersyjne) i Jave, bo pewnie tam też coś
@Massad: cykle są problemem czysto teoretycznym. Przypadek brzegowy, który ani razu przez ostatnie kilka lat pracy z C++ i Rust nie przysporzył mi kłopotu. I co z tego że jest weakref - jak nie masz gwarancji kiedy GC go posprząta. Zasoby muszą być zwalnianie deterministycznie.
A, czyli wskazałeś ticket w libce third-party, która robi rzecz będącą całkowicie poza
Zaraz, zaraz. Ja ich nie muszę przeprowadzać, bo i po co? ( ͡° ͜ʖ ͡°) To Ty wziąłeś sobie za cel porównywanie Pythona i Rusta i rozpowiadanie na forach jaki Rust jest genialny i zwięzły, a Python taki czy owaki, więc
@Krolik: a czemu ma generowac strukturę danych jak robi CLI dla funkcji na podstawie jej argumentów?
@devopsiarz: mozecie moze powiedzieć co macie na myśli w tym kontekście? Ostatnio napisałem dość dużo kodu bazującego na adnotacjach typów i w zależności od tego zmieniających działanie w runtime.
Owszem, możesz type hintować i w runtime sobie sprawdzać typy na podstawie jakichś
isinstanceczy tego typu wynalazków, to może dużo pomóc w wyłapywaniu błędów związanym z typowaniem (porównując z@Massad: np. temu, że potem chcesz dorzucić alternatywnie konfigurowanie z pliku i zamiast dopisać kilka linii to musisz zrobić wszystko od nowa. Nie mówiąc o tym, że konfiguracja jako strktura jest wygodniejsza aby ją przekazywać gdzieś dalej. A tutaj co, jak będziesz mieć 20 paramtrów, to potem 20 paametrów będziesz przekazywał przez kilka poziomów wywołań funkcji?
Problem polega na tym, że opierając się na GC, nie tylko nie będą zwalniane natychmiast, ale nie masz gwarancji, że w ogóle zostaną kiedykolwiek zwolnione. A takie deskryptory plików w domyślnej konfiguracji potrafią się bardzo szybko skończyć (bo domyślnie w wielu systemach jest ich tylko 1024 / proces).
Jezeli chodzi o silnosc typowania to w pythonie jest tak samo silna jak w C++ tylko sprawdzana w czasie wykonania, a nie kompilacji. Jak nie ma przeciazonego operatora to dana operacja nie zostanie wykonana.
Takim dorym porownaniem bylby kod w C++ ktory masowo wykorzystuje Template i iteratory. Tam tak samo.
@Massad: no typ to jest takie samo słabe rozwiązanie jak try w javie. Po pierwsze użycie pliku masz wtedy przyczepione do zasięgu leksykalnego, po drugie musisz pamiętać o tym aby takowego kontekstu użyć lub zawołać ręcznie close. Przy czym ręczne zawołanie close może skończyć się tym że zostanie pominięte jesli poleci wyjątek. Czyli zarządzasz ręcznie a
A jedyny przypadek wyczerpania deskryptorow miałem w c++, bo jednak był o jeden smart pointer za dużo. Od tego czasu pilnuje aby zamykać pliki jak tylko przestają być potrzebne.
Czy ta biblioteka, nie rozwiązuje tego samego problemu co multiprocessing.Pipe?
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Pipe