Dlaczego biblioteka tkinter jest częścią implementacji Pythona? Dlaczego ktoś się zdecydował na stworzenie biblioteki GUI będącej wrapperem na coś tak archaicznego jak Tcl/Tk i umieszczenie jej w standardzie / implementacji pythona? Dlaczego ktoś uznał, że to dobry pomysł? Nie mogli zrobić czegoś zupełnie niezależnego? Ewentualnie nie umieszczać żadnej biblioteki do GUI w standardzie? Przez takie dziwactwa mam wrażenie, że python to jeden wielki burdel.
btw. polecacie coś zamiast tkinter?
Nie wiem, kiedy dokładnie Tkinter powstał, ale wprowadzenie jest z 1999, gdy Python, według wiki, był w wersji 1.5. Wybór był pewnie wtedy mocno ograniczony.
Zamiast jojcyć zacznij używać Qt. TkInter to prawdawna technologia z pradawnym podejściem do niektórych rzeczy, ale jakby nie patrzył można w tym zrobić wszystko co potrzeba do UI.
Bartosz Wójcik napisał(a):
Zamiast jojcyć zacznij używać Qt. TkInter to prawdawna technologia z pradawnym podejściem do niektórych rzeczy, ale jakby nie patrzył można w tym zrobić wszystko co potrzeba do UI.
Qt jest ok, ale ja tu chciałbym podyskutować (pohejtować) na temat tkintera. Liczę, że ktoś przedstawi mi jakieś argument dlaczego ten potworek jest jeszcze utrzymywany przy życiu.
Wyobraź sobie początkującego, który uczy się pythona i chce się nauczyć tworzyć okienka w tymże języku. Natrafia na takiego tkintera, który to jest najpopularniejszą biblioteką do GUI w python i w dodatku jest faworyzowana przez twórców pythona. Okazuje się, że dokumentacja tego czegoś jest biedna i (podobno) trzeba się wspomagać dokumentacją Tk i Tcl, żeby to zrozumieć, a poza tym to w ogóle zupełnie nie rozumie o co chodzi z tym Tcl/Tk (czy ma się tego uczyć?). Sama biblioteka też nie jest jakoś specjalnie user-friendly (Qt jest znacznie prostsze imho) i jakoś specjalnie rozbudowana (np. mało kontrolek). Trzymanie takiego potwora przy życiu skutecznie odstrasza nowych programistów.
@ly000: weźmy prostszy scenariusz: wchodzi sobie nowy użytkownik i chce wysłać Request HTTP. Większość tych nowoczesnych języków ma odpowiednie biblioteki wbudowane. Wystarczy jeden import. No to lecim...!
>>> import urllib
>>> import urllib2
>>> import urllib3
>>> import urllib4
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named urllib4
Uff, dobrze, że przy czwartej wersji wybuchło, bo aż strach tak iterować... To czego zatem użyć, 1, 2, 3...? Otóż każdy Pythonista zgodnie powie, że żadnego, jest zewnętrzny moduł requests, który jest śliczny, nowoczesny i ładnie zaprojektowany i jest de facto standardem używanym wszędzie. I taka jest tu mniej więcej filozofia - baterie są w zestawie, ale w wielu miejscach domyślne wychodzi się poza bibliotekę standardową. I ten użytkownik, który zechce klepać okienka, jak tylko trochę poszuka, to prędko odkryje, że każdy mu będzie tego tkintera odradzał. Ot, jest, jak się chce coś narzeźbić na szybko, ale do każdego poważnego zastosowania lepiej go zastąpić czymś innym.
Czy taka filozofia jest sensowna, to już kwestia dyskusji. Co innego pozostaje? Qt do biblioteki standardowej dodać się nie da - licencje nie pozwalają. Notabene, swego czasu ze względu na jakieś rozdźwięki wśród twórców API Qt sforkowali cały projekt i społeczność Pythona mogła wybierać spośród dwóch wersji: PyQt i PySIde. Tak że, ta strategia odpada. Może zatem należy napisać własne rozwiązanie od zera? To również nie gwarantuje stworzenia porządnego API - to generalnie trudne, a porządne biblioteki wykształcają się "w boju", w istnej dżungli programistycznej, gdzie przeżywa najlepiej przystosowany. A to, co się doda do biblioteki później już trzeba otrzymywać. Efektem tego jest to "bogactwo" standardowych modułów do słania zapytań. Taki Swing w Javie również nie jest specjalnie kochany. To może czekać aż te biblioteki, które się obronią na rynku, zrobią popularność i wtedy włączać je do biblioteki standardowej - vide wspomniane requests? Można i tak. Taką strategię próbuje obecnie wprowadzić C++ i towarzyszy temu cała masa wojen i dysput wobec ludzi, z których każdy ma inną wizję jak to ma wyglądać i działać. I okazuje się, że stworzenie porządnego API, spełniającego wszystkie potrzeby jest cholernie trudne. I teraz trwają podjazdy przeciwko pakowaniu do C++ domyślnej biblioteki do grafiki - dotychczasowe propozycje spotkały się z szeroką krytyką. Część rzeczy zaadaptowano skutecznie z bibliotek Boost (jak Filesystem i ASIO), część weszła z kontrowersjami, pokroju nowych algorytmów range-v3, które okazują się bardziej uciążliwe w używaniu niż to obiecywano. Tak więc Python i jego twórcy zdecydowali się nie iść tą drogą i ilość rzeczy w bibliotece standardowej jest ograniczona. To w sumie rozsądna strategia, przyjmowana i przez inne języki: jak tylko się wyjdzie ze żłobka i opanuje podstawy składni warto wyjrzeć na szeroki świat i zobaczyć, co jest popularne i co można wykorzystywać. A jest tego dużo: przegląd warto zacząć od Awesome Python.
Można się jeszcze zapytać, czemu się nie sprząta tego śmietnika i czemu by się nie pozbyć całkowicie niektórych rzeczy...? Ano kompatybilność wsteczna. I bez usuwania całych bibliotek przechodzenie od 2 do 3 było (i jest) długim, bolesnym procesem. Każda zmiana niszczy komuś workflow.
Tak jak już ktoś napisał, Tkinter wszedł do pytona lata temu (pewnie większość z forumowiczów była jeszcze w przedszkolu ) a do języka łatwiej jest coś dodać niż zabrać ze względu na zgodność wsteczną. Ci, co przenosili programy z Python 2 na 3, to wiedzą ile zmiana printa potrafiła wymusić pracy. poza tym programowanie jest taką piękną działką, że ma się wybór. Jest bardzo dużo programów, które żyją dłużej niż 2 lata, a nawet więcej niż 10 i uśmiercenie takiej biblioteki ze standardu oznaczałoby brak możliwości migracji na nowe wersje języka i utratę dużej ilości ważnych funkcjonalności.
Jakby do Pythona dołączyli Qt w zestawie, to ważyłby przynajmniej dwa razy tyle :D
Tk chyba pod tym względem jest dość optymalny, a do prostego GUI na nasze konsolowe apki da radę.
Do C/C++ niczego nie ma w zestawie. Chyba najbliżej tam jest do WinAPI, a to i tak nie jest przenośne.
Tkinter jest spoko do prostych gui. Wraz z zaawansowaniem gui jednak ten czar pryska i jest duzo zabawy w kodzie, ktory suma sumarum wyglada zle. Osobiscie uwazam, ze zrozumienie tkintera na poziomie powiedzmy sredniozaawansowanym przelozy sie na lepsze rozumienie budowania gridow itp np. w takim css ;) Mi osobiscie swojego czasu to mocno pomoglo a z takim tkinterem troche walczylem.
Być może jestem odosobnionym przypadkiem, ale ja tam lubię Tkinter za jego prostotę, ale zgadzam się że jest archaiczny i dokumentacja ssie. Poza tym tkinter chyba tylko na windowsie instaluje się wraz z pythonem, na linuxie żeby z niego skorzystać trzeba np. wpisać ekstra polecenie apt-get install python3-tk.
@Spearhead: No dobrze, ale co stoi przeciwko temu, żeby mogli tą bibliotekę chociaż porządnie udokumentować?
Poza tym, w między czasie został wydany python3 (2008), który nie było kompatybilny z poprzednikiem, ale mimo wszystko tkinter został przeniesiony. Mogliby go chociaż zmodernizować albo usunąć.
Tak więc Python i jego twórcy zdecydowali się nie iść tą drogą i ilość rzeczy w bibliotece standardowej jest ograniczona.
I dlatego dodali tkinter do standardu? Gdyby tak było, to by w ogóle tego nie dodawali.
według wiki, był w wersji 1.5. Wybór był pewnie wtedy mocno ograniczony.
Był lepszy wybór. Mogli to po prostu zrealizować jako zewnętrzną bibliotekę do GUI, bez upychania tego do standardu. Albo mogliby wpierw stworzyć niezależne API do GUI, a potem co najwyżej zaimplementować to API z użyciem Tcl/Tk i nie wspominać o tym dziwactwie użytkownikowi.
Robienie biblioteki do GUI opartej o przestarzałą technologie, o której mało kto w ogóle słyszał, a następnie umieszczanie jej w standardzie powoduje, że standard tego języka do burdel. Przykład z urllib2,3,4 jeszcze bardziej mnie do tego przekonuje. Inne języki przynajmniej starają się trzymać jakąś higienę przy umieszczaniu bibliotek w standardzie. Chyba w żadnej innej popularniej technologii nie ma takich dziwactw - gdzie indziej jakoś mogli tego uniknąć.
@ly000
No dobrze, ale co stoi przeciwko temu, żeby mogli tą bibliotekę chociaż porządnie udokumentować?
Akurat nie tylko to API mogliby lepiej udokumentować, stąd też swego czasu punktem wejścia dla bibliotek w Pythonie było PYMOTW (jest też uaktualnienie do wersji 3). Generalnie dokumentacja zawiera głównie odgórny opis API, a nie tutoriale, jak ktoś potrzebuje czegoś więcej, to szuka książek, wpisów na SO (a wcześniej pytało się na usnecie, IRCu i grupach Google) lub istniejących próbek kodu. I to jest mocno uniwersalny problem. C++ nie ma wcale oficjalnej dokumentacji - masz jedynie standard, 1200 stron technicznego dokumentu. PHP było kiedyś sławne z tego, że w dokumentacji były dozwolone komentarze i trzeba je było czytać, bo w nich użytkownicy podawali rady wskazówki i pułapki, których trzeba było unikać. Inne języki też jedynie podają referencyjny słownik zawartości swoich modułów i pakietów. Pisanie dokumentacji jest trudne, co potwierdzi każdy, co kiedyś próbował.
Poza tym, w między czasie został wydany python3 (2008), który nie było kompatybilny z poprzednikiem, ale mimo wszystko tkinter został przeniesiony. Mogliby go chociaż zmodernizować albo usunąć.
Mogli, ale pewnie woleli zostawić jak jest dla tych, którzy tego z jakichkolwiek powodów używają aby nie dostarczać im więcej zmartwień (i tak migracja była, jak wspomniałem, bolesna).
I dlatego dodali tkinter do standardu? Gdyby tak było, to by w ogóle tego nie dodawali.
20 lat temu trudno było mówić o standardach, Python ciągle się kształtował jako język, jednocześnie konkurując na rynku i budując pozycję. Wiadomo, że jakby Guido miał kryształową kulę i mógł przewidzieć przyszłość to wiele rzeczy zrobiłby inaczej. Ale projektowanie i rozwój języka to skomplikowany ciągły proces. I tak, można się natknąć na artefakty wynikające z historii, stąd konwencje i zalecenia, gdy doświadczenie nauczyło nas lepiej.
Mogli to po prostu zrealizować jako zewnętrzną bibliotekę do GUI, bez upychania tego do standardu.
Mogli. Może nawet żałują.
Albo mogliby wpierw stworzyć niezależne API do GUI, a potem co najwyżej zaimplementować to API z użyciem Tcl/Tk i nie wspominać o tym dziwactwie użytkownikowi.
A to już omawiałem - stworzenie jednolitego API spełniającego wymagania dla każdego to nie takie proste hop siup. Okazałoby się po 20 latach, że Qt i inne frameworki tak zdryfowały, że ich API nijak się nie przekłada na to domyślne i trzeba i tak stosować zewnętrzne biblioteki - dalej byś narzekał.
Robienie biblioteki do GUI opartej o przestarzałą technologie, o której mało kto w ogóle słyszał, a następnie umieszczanie jej w standardzie powoduje, że standard tego języka do burdel.
W 1999 jeszcze nie była przestarzała.
Inne języki przynajmniej starają się trzymać jakąś higienę przy umieszczaniu bibliotek w standardzie. Chyba w żadnej innej popularniej technologii nie ma takich dziwactw - gdzie indziej jakoś mogli tego uniknąć.
Babole w bibliotekach standardowych w innych językach się zdarzają. Typowym przykładem jest std::vector<bool> w C++. Swing w Javie też nie jest chyba obecnie specjalnie lubiany. JavaScript poszedł inną drogą: nie ma biblioteki standardowej wcale, więc w NPM w repozytorium są 3-linijkowe pakiety do podstawowych operacji pokroju is_promise ściągane automatycznie przez miliony projektów; raz za czas któryś z nich się psuje i wtedy siada im cały ekosystem.
@ly000: Mam wrażenie, że Twój wpis dotyczący nowych programistów idealnie pasuje do mnie. Przez wiele lat zajmowałem się zarządzaniu projektami od strony klienta, natomiast do programowania wróciłem niedawno. Za czasów studiów i pierwszej pracy zawodowej pisałem w C++. Teraz należało wybrać coś nowszego, szybszego w nauce i dającego wymierne efekty w krótkim czasie. Postawiłem na Pythona, a jeżeli chodzi o GUI zdecydowałem się na Tkinter. Cóż mogę powiedzieć, ilość materiałów w sieci jest tak duża, że jeżeli tylko dysponujemy wystarczającą ilością czasu można bez większych problemów poznać ten framework. Ja szczególnie polecam TkDocs (https://tkdocs.com/tutorial/index.html) i effbot.org (http://effbot.org/tkinterbook/tkinter-index.htm).
Z mojej perspektywy Tkinter to rozwiązanie w stylu: "szybko, łatwo i przyjemnie na desktopie": nie wymagający instalacji, prawdopodobnie najbardziej popularny framework w Pythonie, który oferuje intuicyjny interfejs i przyzwoity zestaw widgetów, które można dodatkowo trochę podrasować korzystając z modułu tkinter.ttk.
Mnie Tkinter nie odstraszył, choć faktycznie szukam od jakiegoś czasu innej biblioteki, która pozwoliłaby na przeniesienia mojego kodu na urządzenia mobilne. Niestety ani Qt ani PySide czy wxPython nie dają takiej możliwości. W tej sytuacji jedynym dostępnym rozwiązaniem wydaj się Kivy...
Czy jako alternatywę do Tkintera, polecilibyście Kivy?
programoteq napisał(a):
szukam od jakiegoś czasu innej biblioteki, która pozwoliłaby na przeniesienia mojego kodu na urządzenia mobilne. Niestety ani Qt ani PySide czy wxPython nie dają takiej możliwości. W tej sytuacji jedynym dostępnym rozwiązaniem wydaj się Kivy...
Na Twoim miejscu spróbowałbym https://flutter.dev/
Wbudowany interpreter Pythona IDLE jest w Tcl/TK. Zastanawia mnie co kogo obchodzi, co jest w standardzie, jeśli można dodac swoje moduły? Zresztą podczas wdrażania Tcl było dość popularne. Nieodpowiedzialnym było by teraz zrywanie z jego wsparciem jak już są miliony skryptów używające gui w Tcl.
somedev napisał(a):
Wbudowany interpreter Pythona IDLE jest w Tcl/TK. Zastanawia mnie co kogo obchodzi, co jest w standardzie, jeśli można dodac swoje moduły? Zresztą podczas wdrażania Tcl było dość popularne. Nieodpowiedzialnym było by teraz zrywanie z jego wsparciem jak już są miliony skryptów używające gui w Tcl.
Podczas gdy deweloperzy innych języków zastanawiają się 100 razy zanim wrzucą coś do standardu, deweloperzy pythona uważają, że to nie ma znaczenia co jest w standardzie a co nie jest. Zauważyłem, że społeczność pythona jest z tego względu dość specyficzna. Gdybyś coś takiego powiedział programiście c++/c#/java, to by dostał białej gorączki. Btw. ten IDLE to też niezłe dziwactwo. Wolałbym, żeby nie instalowały mi się takie bezużyteczne programy domyślnie z pythonem. Chyba nie ma tu już nad czym dyskutować, bo to jest po prostu kwestia podejścia. Mi się ono nie podoba, gdyż ja wolałbym obcować z technologią, w której panuje porządek, a wam to chyba wszystko jedno ¯\_(ツ)_/¯. Można po prostu to ignorować - też jakieś podejście. W pythonie jest również wiele innych brzydkich rzeczy - np. nazewnictwo modułów, czy te przeklęte podkreślniki ヽ( ͠°෴ °)ﾉ
Czy jako alternatywę do Tkintera, polecilibyście Kivy?
Kivy jest bardziej frameworkiem pod aplikacje mobilne. Na systemach stacjonarnych część ograniczeń może przeszkadzać, np. można mieć tylko jedno okno programu. Ale jak ktoś chce coś wyrzeźbić na szybko to może być.
Podczas gdy deweloperzy innych języków zastanawiają się 100 razy zanim wrzucą coś do standardu, deweloperzy pythona uważają, że to nie ma znaczenia co jest w standardzie a co nie jest.
Nie jest to sprawiedliwe, ponieważ porządki w bibliotece były, są i będą:
Ten drugi PEP jest szczególnie warty przejrzenia, bo świeży (2019), jak widać nieco staroci zostanie zrzucone wraz z wersją 3.10. Na przykład cgi - pamięta ktoś jeszcze pisanie skryptów CGI do serwowania stron w pradawnych czasach...?
Ewidentnie uczepiłeś się tego Tkintera, który akurat zostaje, bo jest wystarczająco użyteczny, być może przez jakieś kiepskie doświadczenia.
Gdybyś coś takiego powiedział programiście c++/c#/java, to by dostał białej gorączki.
O, akurat w C++ kosmiczne wojny się toczyły o różne rzeczy w standardzie, chociażby o domyślną bibliotekę do multimediów i GUI.
To Tobie wydaje się, że nie ma porządku. Tak się składa, że jestem od lat również programista C++ oraz C#. Dla przykładu uważam, że UWP jest totalnym strzałem kulą w płot ale nie lamentuje z tego powodu, ponieważ to mnie nic nie obchodzi. Nie robię żadnych usingów do tego, ani moje dll nie puchnie. Używam sobie po cichu Windows Forms i jest spoko. Zupełnie nie obchodzi mnie, że w standardzie .NET jest UWP. Tak samo nie obchodzi mnie, że w najnowszym .net core jest kontener DI, bo od lat używam Autofaca i tyle. Moim zdaniem zastanowili się jak coś wrzucali ale to było xx lat temu i dlaczego teraz mają to wyrzucać? Twoje podejście jest krótkowzroczne i dziecinne. Python to 1991r. PyQT miało swoje początki w 2009 a Kivy w 2011, a IDLE istnieje od 1998, czyli tkinter jest co najmniej 11 lat starszy od QT. Co mieli wtenczas do standardu wdrożyć?
ly000 napisał(a):
Ewentualnie nie umieszczać żadnej biblioteki do GUI w standardzie?
@ly000: Jakieś jędolenie... A konkretnie?
tkintera? :)tkinterze jest naprawdę bolesne w porównaniu z innymi GUIami? Nie biorąc oczywiście pod uwagę czegoś dużego, bo do dużych rzeczy w Pythonie (czy to GUI czy co innego) i tak się używa zewnętrznych bibliotek...!koszalek-opalek napisał(a):
ly000 napisał(a):
Ewentualnie nie umieszczać żadnej biblioteki do GUI w standardzie?
@ly000: Jakieś jędolenie... A konkretnie?
- A możesz napisać jakim cudem niedodawanie żadnego GUIa jest lepsze od dodania
tkintera? :)
@koszalek-opalek
Najlepiej jakby biblioteka standardowa zawierała tylko rzeczy uniwersalne, dostępne na wielu platformach, a GUI nie należy do takich rzeczy. Oczywiście komuś takie podejście może nie odpowiadać, on chciałbym żeby standard było API znacznie szerszy jak np. w Javie. Rozumiem, ale dlaczego w takim razie w standardzie pythona nie znajduje się wiele, o wiele ważniejszych rzeczy? Przecież bez instalacji zewnętrznych bibliotek nie da się praktycznie zaprogramować żadnej aplikacji, która niosłaby jakąkolwiek "wartość biznesową". Nawet do wielu podstawowych struktur trzeba użyć zewnętrznych bibliotek. Biblioteki umieszczane w standardzie są traktowane przez projektantów pythona bardzo wybiórczo.
O standard należy dbać i nie wrzucać tam wszystko na pałę. Zadaj sobie pytanie dlaczego w standardzie nie znajduje się np. API do Minecrafta. Przecież "lepiej, żeby było, niż nie było", co nie? No nie, bo to potem niejako zmusza programistów do obcowania z tym burdelem. Poza tym to jest niepotrzebne faworyzowanie biblioteki, które są po prostu słabe.
Dokumentacja tkintera mówi, że należy się posługiwać dokumentacją pradawnej technologi Tcl/Tk, co już w ogóle jest kosmosem. Wyobrażasz sobie, żeby jakaś biblioteka standardowa np. w c++ była wrapperem do biblioteki napisanej w jakimś starożytnym języku i w swojej dokumentacji miała napisane, że należy korzystać z dokumentacji jakiegoś Fortrana czy czegoś takiego? Ja też nie.