Trzeci dzien bawie sie Python'em :D.
Rewelacyjna dokumentacja na python.org :D
PyCharm darmowe z niezlymi pluginami :D.
Debugger nawet nie wiem skad mi sie wzial, dziala default'owo :D.
Pakiety same sie sciagaja :D.
Co napiszesz dziala tak jak oczekujesz :D.
I love Python :D
Ech.. Szkoda, że się nie nauczyłem. Teraz się muszę męczyć w jakiś Delphi, Visual Studio gdzie żeby cokolwiek zrobić to trzeba coś w jakimś menu kliknąć :-)
No ja dzięki Pythonowi zajarzyłem obiektowość, referencje itp.
Po topornym klepaniu w C i C++ czułem, że nauka programowania w Pythonie pozwoliła mi szybciej przejść przez "podstawy", które już dawno powinienem był mieć...
Jednak po okresie fascynacji przyszła pora wrócić do języków, w których utrzymanie kodu jest "centralnie sterowane" i po Javie, dobrze mi z C#...
W Pythonie zdecydowanie fajniej sie pisze niz pozniej debuguje/poprawia duzy projekt napisany dawno przez kogos innego :P
Kiedyś napisałem, że na studiach (informatyka) w PL powinni w końcu zamienić obowiązkowy (od dziesięcioleci) na pierwszym roku C na Python.
Reakcja grupy "Obrażonych uczuć programistycznych tylko C" była porównywalna do reakcji na reklamę na 4P "Swetrów i Piwniczaków".
W USA nie mają problemów z tym, że zaczyna się naukę od Pythona.
A referencja? Miałem na myśli C, Jakbym miał ma myśli C++ to narzekałbym na wiele innych rzeczy :) @alagner zgubiłeś kontekst. Dla mnie kontekstem był wybór pierwszego języka programowania. C Jest złym wyborem. Asm jest oczywiście jeszcze gorszy. Python jest dobrym wyborem, ale IHMO Scheme był doskonałym wyborem. Szkoda że po 25 latach odeszli od tego na MIT :(
Choroba, ja nie jestem nawykły (na codzień piszę kod systemowy), ale dynamiczne typowanie bardziej mi przeszkadza niż pomaga a "better explicit than implicit" powoduje miejscami takie ilości wywołań konstruktorów że aż mnie to boli. Tzn. nie mówię, Python jest szybki w prototypowaniu, analizator logów Wiresharka prościej mi było na szybko "wypythonić" niż pisać dissector w C, ale w pewnych zastosowaniach zdecydowanie bardziej doceniam błąd kompilacji niż exception w rutime.
@BraVolt: ale kadra na studiach jeszcze musiałaby się czegoś douczyć...
Pojedyncze jednostki, jak mogą to wprowadzają coś innego niż C. Np. w Rzeszowie jeden prowadzący na wstępie do programowania dla "nie-informatyków" robił zajęcia w Ruby.
Ale mógł sobie na to pozwolić pewnie właśnie dlatego, że prowadzący z innych przedmiotów nie będą potem wymagać od studentów znajomości języka C, bo to nie kierunek Informatyczny.
Młody, naiwny...
Poza tym, tak Python jest spox
Rewelacyjna dokumentacja na python.org :D
Dokumentacja w sumie spoko, ale z nią jest jeden podstawowy problem - jest bardzo obszerna i często trzeba wiedzieć, że coś istnieje, zanim się to znajdzie w dokumentacji. Dokumentacja po prostu opisuje wszystkie elementy języka po kolei, natomiast brakuje trochę wysokopoziomowego przeglądu różnych koncepcji - czyli jak się różne typowe problemy w Pythonie rozwiązuje. A że język jest bardziej skomplikowany niż Scala, to można dostać zawrotu głowy i kompletnie się pogubić w ficzerach języka i biblioteki - jedną rzecz można zrobić na kilka sposobów.
Do tego Python słabo wspomaga odkrywanie rzeczy w naturalny sposób w trakcie pisania (np. w innych językach daję "." po obiekcie i dostaję w IDE wszystko co mogę z obiektem zrobić). Wiele rzeczy jest w nieoczywistych miejscach. Dużo czasu upłynęło, zanim dowiedziałem się, że np. długości listy nie znajdę w dokumentacji listy, bo to tego służy funkcja top-level len() i że jest wiele takich ogólnych funkcji, których istnienie trzeba sobie wbić w pamięć :D Z drugiej strony dokumentacja inline działająca bezpośrednio w edytorze jest dość uboga - często jedno lakoniczne zdanie, brak udokumentowanej obsługi błędów i brak przykładów, a sygnatura metody niewiele mówi i wtedy często trzeba właśnie sięgać do tej na python.org a nieraz i do kodu źródłowego funkcji. Szczególnie jest to widoczne jak zaczynasz używać bibliotek third-party, które często w ogóle nie mają dokumentacji. Spowalnia to naukę i kodowanie. W jęykach ze statycznym systemem typów przynajmniej z sygnatury da się coś wyczytać.
Zdecydowanie brakuje mi czegoś takiego jak np. Rust book, co można przeczytać w kilka godzin i być względnie produktywnym, gdzie omówiono język przez pryzmat problemów i koncepcji a nie skupiając się wyłącznie na samym języku.
PyCharm darmowe z niezlymi pluginami :D.
To jest standard dla większości języków, więc to że darmowe, to niewielka zaleta.
Niestety wsparcie jakie daje plugin do Pythona to trzecia liga (pierwsza to Java/C#/C++/Kotlin/Scala, Rusta/Go bym umieścił jeszcze w drugiej, choć pretenduje do pierwszej).
Wczoraj zmieniłem nazwę jednego pliku. Importów automatycznie nie poprawił bo po co i potem grepowanie całego projektu żeby zrobić głupie replace :D
Debugger nawet nie wiem skad mi sie wzial, dziala default'owo :D.
Tak, debugger jest, a w Pythonie trzeba go używać bardzo często. Znacznie częściej niż w innych językach. Nie wiem czy to jest zaleta.
Pakiety same sie sciagaja :D.
Oj, pakiety to jest akurat masakra. Jedna wspólna przestrzeń dla wszystkich pakietów, niezależnie od projektu. Wystarczy dwie biblioteki potrzebujące innej wersji jakiejś zależności i się wszystko sypie.
Dla porównania w takim Rust możesz mieć dwie wersje tej samej biblioteki w jednym projekcie i się nie pogryzą tak długo jak nie są używane w jednym miejscu na raz.
W Pythonie aby to obejść ludzie powymyślali cuda na kiju jak środowiska wirtualne i masowo używają dockera aby zapakować aplikację. W żadnym innym języku nie spotkałem takiej ilości dodatkowej złożoności (accidental complexity) związanej z paczkowaniem.
Co napiszesz dziala tak jak oczekujesz :D.
Coooo?! W 9/10 przypadkach kod po napisaniu nie działa od razu jak oczekuję. A nawet jak działał wcześniej, wystarczy niewielki refactoring i zwykle już nie działa. Ten poziom "niedziałania" kodu miałem ostatnio w liceum, kiedy uczyłem się programować. Ten język jest tak frustrujący, że po prostu dawno nie spotkałem czegoś takiego.
Najbardziej wkurzające jest to, że nie działa zwykle przez jakąś pierdółkę, typu gdzieś tam wlazł None a miał być obiekt i zabrakło sprawdzenia, albo gdzieś coś zwraca np. dwa wyniki a nie jeden, bo nie doczytałem dokumentacji na stronie (a w IDE nie było). I w sumie to nie byłoby nic takiego, bo przecież są unit-testy, które to zawsze łapią, jednak: (1) nie wszystko daje się łatwo i szybko unit-testować, np. integracja z zewnętrznymi systemami może trochę więcej czasu potrwać jeśli chodzi o setup; (2) test jak się wywali to nie daje tak szczegółowej informacji o wystąpieniu błędu jak komunikat kompilatora w statycznym języku - czas naprawienia takiego błędu w Pythonie jest znacznie dłuższy; trzeba wyciągać debugger.
Podsumowując:
moja produktywność w Pythonie jest mniejsza po kilku miesiącach nauki i pisania w nim realnego firmowego projektu niż moja produktywność po miesiącu weekendowego pisania hobbystycznego projektu na boku w Rust, który ponoć jest potwornie trudny. Porównuję z Rust, bo mniej więcej w tym samym czasie zacząłem poznawać oba.
len(list), list.remove(item) i żeby było ciekawiej nawet del list[item]. Ogólnie pierdzielnik składniowy.
ify się pisze w innej kolejności w zależności od tego czy są wyrażeniem czy instrukcją sterującą.
@Krolik: "Upvotowałem" Twój post, ale to nie znaczy, że się ze wszsystkim zgadzam :) Otóż nie, jak wpiszesz w Pythonie kropkę po obiekcie, to dostajesz podpowiedzi, nawet w konsoli, nie mówiąc o IDE. W dokumentacji listy, jak najbardziej jest informacja o len:
| __le__(self, value, /)
| Return self<=value.
|
| __len__(self, /)
| Return len(self).
|
| __lt__(self, value, /)
| Return self<value.
Chyba też nie jest winą Pythona, że ktoś wypuszcza biblitekę bez dokumentacji. A dalej tak, w pakietach jest trochę burdel, ale z pip, virtualenv i requirements.txt da się sporo ogarnąć. To tyle, acha, z tym "Co napiszesz działa tak jak oczekujesz" to chodzi bardziej o to, że ideę algorytmu, tak jak go rozmumiemy i tak jak jest w pseudokodzie, można w Pythonie łatwo zapisać.
__len__, ale widzisz, teraz trzeba wiedzieć, że to jest magiczna metoda, która jest wołana przez ten główny len(). Te podkreślniki mnie początkowo przestraszyły i zignorowałem te metody. Przy okazji pomysł, żeby kontrolować prywatność metod / pól przez nazwę (_) a nie słowo kluczowe jak w innych językach jest obiektywnie bardzo słaby.
acha, z tym "Co napiszesz działa tak jak oczekujesz" to chodzi bardziej o to, że ideę algorytmu, tak jak go rozmumiemy i tak jak jest w pseudokodzie, można w Pythonie łatwo zapisać.
Ok, to jest argument bardzo często podnoszony jako zaleta języków skryptowych (nie tylko Pythona). Że można szybko i prosto napisać, i że wygląda prawie jak pseudokod.
Zobaczmy jak to wyglądało w projekcie, w którym ostatnio jestem. Musiałem wywalić duplikaty z listy. Oczywiście nikt takich rzeczy nie pisze od zera. Np. w Scali zrobiłbym to tak:
val list = List(1,5,2,1,2)
val newList = list.distinct // List(1,5,2)
W "niskopoziomowym" Rust jest troszkę więcej ceregieli, bo trzeba przekształcić w iterator i z powrotem, bo tak jest uniwersalniej:
use itertools::Itertools;
let list = vec![1,5,2,1,2];
let new_list: Vec<_> = list.into_iter().unique().collect(); // vec![1,5,2]
A jeśli lista byłaby posortowana, to można użyć specjalistycznego dedup() które działa bez alokacji na stercie i jest bardziej cache-friendly:
let list = vec![1,1,2,2,5];
let new_list: Vec<_> = list.into_iter().dedup().collect(); // vec![1,2,5]
No i szczerze w Pythonie spodziewałem się czegoś podobnego.
Najpierw rzut okiem na listę metod dla listy:
dedup? nie ma
unique? nie ma
distinct? nie ma
remove_duplicates? nie ma
Mogę zrobić zbiór przez set(), ale stracę kolejność...
Skończyły mi się pomysły, rzut oka w dokumentację. Nie ma nic.
Chwilka, wiem, przecież w Pytonie jest jeszcze itertools - iteratory na sterydach! Dokumentacja itertools:
powtarzanie elementu, nie to nie to ...
grupowanie, no może jakoś by się dało, ale strasznie naokoło...
kombinacje, permutacje, nie to też nie to,
parzenie kawy i herbaty... no nie, to też nie teraz...
koniec listy
Dobra, poddaję się, idę na StackOverflow.
Tamże najwyżej punktowana odpowiedź (serio?!):
for i in mylist:
if i not in newlist:
newlist.append(i)
No dobra, ale to jest O(n^2) myślę sobie, musi być coś lepszego. Kawałek niżej jest:
seen = {}
new_list = [seen.setdefault(x, x) for x in my_list if x not in seen]
Ostatecznie można też przez bezpośrednią konwersję do zbioru o ile się weźmie OrderedDict:
from collections import OrderedDict
list(OrderedDict.fromkeys(lseparatedOrbList))
To jest akceptowalne, ale nadal bardzo "nie-wprost", bo deduplikacja jest tylko efektem ubocznym działania zbioru. A ja zbioru w ogóle nie potrzebowałem.
To tyle w kwestii tej słynnej czytelności i ekspresywności. Polega ona chyba na pisaniu od zera oczywistych rzeczy, a "batteries-included" to jedynie mit.
Może względem C i Javy się broni, ale serio inne języki poszły do przodu.
BTW: Żeby nie było, że się przyczepiłem tylko przez przypadek jednej rzeczy. Kolejna rzecz, która wydaje się serio na maksa podstawowa a jej nie ma, to znalezienie pierwszego elementu na liście, który spełnia warunek. Czyli coś co w wielu językach jest pod postacią metody lub funkcji find(). A w Pythonie... nie ma. No, po prostu, musisz napisać sobie sam:
unique_everseen i first_true z modułu more_itertools robią to, co chcesz.
Krolik napisał(a):
No i szczerze w Pythonie spodziewałem się czegoś podobnego.
list1 = [1,5,2,1,2]
pd.Series(list1).drop_duplicates().to_list() # [1, 5, 2]
@Krolik: Prawda, ale bym się z tego powodu z mostu nie rzucił :)
@dedicated: Nie zawsze ktoś chce dociągać pandas do projektu.
requests jest de-facto standardem w wysyłaniu zapytań, numpy w obliczeniach matematycznych itd. pandas jest powszechnie używany w przetwarzaniu danych, ale too, żeby każdy projekt go potrzebował to raczej bzdura.
To już raczej more-itertools albo iteration_utilities...
@PerlMonk:
Python 3.6.8:
>>> set(iter([1,2,2,3,5,3,6,3,76,3,1,0,-2,-3]))
{0, 1, 2, 3, 5, 6, 76, -3, -2}
Kolejność stracona.
Python jest przereklamowany.
O ile mam sentyment dla Pythona, to jednak nie chcę w nim pisać.
Jakby jeszcze był szybki. Jakby był niskopoziomowy. Jakby się kompilował do kodu natywnego albo w łatwy sposób mógł odpalać w przeglądarce (teoretycznie można, ale czy to się opłaca? Kiedyś sprawdzałem na jakiejś stronie z REPLem do Pythona i z kilka MB ważył sam interpreter skompilowany do JS. Ciekawe, jak z Wasm to wychodzi).
Owszem, jest ekspresywny, ale inne języki nadrobiły braki, jak również powstały całkiem nowe języki, które też są w miarę ekspresywne. Poza tym w Pythona łatwo jest wejść, ale trudno go opanować (ja pisałem kiedyś w Pythonie, ale nigdy nie osiągnąłem masterki w tych wszystkich trickach, np. zagnieżdżonych list comprehension i innych dziwactwach).
Z drugiej strony Python ma biblioteki do machine learning i ma Django, więc ma on swoje zastosowanie widać i chyba to powoduje taki boom na niego.
Poza tym jest to elegancki język i z niskim progiem wejścia, więc np. lepiej, żeby ktoś się uczył Pythona jako pierwszy język niż jakiegoś JavaScriptu, gdzie na dzień dobry masz ileś WTFów.
wtfów gdy projekt sie rozrasta
Ani się fajnie w Pythonie nie pisze ani się w Pythonie fajnie nie debugguje, Python powinien zostać w swoim obrębie Data Science i nie wychodzić poza ten obszar.
Nie wiem jak wy, ale ja pisząc coś w Pythonie nie widzę jakiegoś takiego funu z robienia tego, całkiem inaczej mi się pisze w Javie czy w TS niż w Pythonie
Tak w ramach eksperymentu proponuję żeby OP, @spartan24, pobawił się teraz 3 dni Rustem i dał nam znać jakie ma wrażenia.
moja produktywność w Pythonie jest mniejsza po kilku miesiącach nauki i pisania w nim realnego firmowego projektu niż moja produktywność po miesiącu weekendowego pisania hobbystycznego projektu na boku w Rust, który ponoć jest potwornie trudny. Wobec tego proponuję empirycznie sprawdzić, czy inne osoby również podzielą ten pogląd i będą miały analogiczne doświadczenia, skoro Rust jest przywoływany jako przykład języka lepszego/bardziej ekspresywnego/najwyraźniej łatwiejszego w opanowaniu.
@Spearhead: jestem juz sporo zaawansowany w przepisywaniu sporej aplikacji z javy do pythona (drugie do pierwszego to jak niebo a ziemia)
i po prostu mi sie nie chce. Poza tym musze jedynie dodac, ze zadnego dyskomfortu z powodow opisanych wczesniej w zadnym stopniu nie odczuwam (no moze poza implementacja interfejsow, a wlasciwie ich brak i koniecznosc kombinowania) no ale pewnie dlatego ze jestem zaj....tym programista :D
Python jest najlepszy na świecie. Dziękuje zamykam temat.
A tak serio, to patrząc po zapotrzebowaniu na prace w pythonie to bez szału. Troche zaczyanm załowac że w .net nie poszedłem, duzo łatwiej o prace dla juniorkow.
PYTHON jest fajny ale 100x wolniejszy niż C. Pomyśleć tylko ile prądu marnowane jest przez te wszystkie serwery które, uruchamiają strony napisane w Pythonie...
ple napisał(a):
PYTHON jest fajny ale 100x wolniejszy niż C. Pomyśleć tylko ile prądu marnowane jest przez te wszystkie serwery które, uruchamiają strony napisane w Pythonie...
Wyobrażam sobie ile prądu byłoby marnowane na deweloperkę, gdyby te strony były robione w C...
ple napisał(a):
PYTHON jest fajny ale 100x wolniejszy niż C. Pomyśleć tylko ile prądu marnowane jest przez te wszystkie serwery które, uruchamiają strony napisane w Pythonie...
Transport morski jest znacznie bardziej ekonomiczny, niż kolejowy, a ten jest bardziej ekonomiczny niż drogowy. Pomyśleć, ile energii się marnuje bo ludzie jeżdżą na zakupy i do pracy samochodem zamiast popłynąć łódką :)
Język wybiera się pod kątem zadania, nie poboru energii. To raz.
Dwa, porównujesz Pythona z C, a powinieneś porównywać z innymi technologiami nadającymi się do jakiejkolwiek formy webdevu od strony backendowej:
Tu porównanie nie będzie już aż tak drastyczne, każda z tych technologii na swój narzut przez interpretery, maszyny wirtualne, dodatkowe poziomy abstrakcji (choćby namiętne stosowanie refleksji przez narzędzia JVMowe) etc.
Trzy, C teoretycznie może jest szybsze (tj według prostych benchmarków) ale szczerze wątpię, że przeciętny backendowiec umiałby napisać drastycznie szybszą aplikację webową w C niż w swoim wiodącym języku.