Modernizing Python's IDLE(tkdocs.com)
tkdocs.com
Modernizing Python's IDLE
http://www.tkdocs.com/tutorial/idle.html
42 comments
Yap first experience with Python for me was via IDLE.
Remember reading about it, downloading, installing, launching IDLE, typing the first program and running it. Granted it was 16 years ago but that was very helpful and I remember being wow-ed by how easy, fast and simple everything was.
After I had quickly switched to emacs for actual coding, but that initial impression made a huge difference.
Remember reading about it, downloading, installing, launching IDLE, typing the first program and running it. Granted it was 16 years ago but that was very helpful and I remember being wow-ed by how easy, fast and simple everything was.
After I had quickly switched to emacs for actual coding, but that initial impression made a huge difference.
Exactly the target audience. I'm not a hardcore Python guy, but got involved because I had reason to try IDLE again recently, and after the initial "oh my $DEITY this is embarrassing" realized that not much effort would be needed to bring it up to the "entirely reasonable" level.
Gang:
Here's a relevation that I only, just now, realized.
Python is named after the Monty Python gang. This I knew.
IDLE is a play off of Eric Idle. How have I never realized this before?
Here's a relevation that I only, just now, realized.
Python is named after the Monty Python gang. This I knew.
IDLE is a play off of Eric Idle. How have I never realized this before?
Oh, then you've got some surprises waiting for you in the docs. I can't remember the specifics years later, but I recall thinking "odd that $SOMETHING <could have been the 'spam and eggs' thing> is sprinkled throughout the docs. I wonder why...oh."
It took me a while to figure out why I kept coming across references to the Cheeseshop. Turns out that's why PyPI has that little quote at the bottom.
https://wiki.python.org/moin/CheeseShop
https://wiki.python.org/moin/CheeseShop
Also the inspiration for the wheel packaging format. As in cheese wheel.
(Not sure if troll, but I'll bite.) Don't feel bad. It took me a few years to realize that. It stands in contrast to the official coding examples, all of which are way longer than 4 bytes.
Yeah, that's also why they tend to use 'spam' and 'eggs' instead of 'foo' and 'bar' in a lot of the official docs.
Something else that blew my mind: Jupyter was named after JUlia, PYthon, and R.
And the Calysto Jupyter kernel project is based on the fact that the Jupyter logo is missing one of the Galilean moons. Naming is fun.
You mean PYThon
I teach Python to high school students on a regular basis, and I'm really looking forward to seeing this project completed.
Most of my students start out with zero technical experience, and simple things like installing a text editor just become one more hurdle they need to get past in order to start programming. Having a decent, usable text editor bundled with the language itself will be really helpful for absolute beginners.
Most of my students start out with zero technical experience, and simple things like installing a text editor just become one more hurdle they need to get past in order to start programming. Having a decent, usable text editor bundled with the language itself will be really helpful for absolute beginners.
Of course a friendly REPL is part of any good IDE, but I could not have learned Python as fast as I did without DreamPie[1]. It's basically an IDLE that separates the input from the output—color highlighted as well. It seems small, but at least for me it really made a big difference.
[1] http://www.dreampie.org/
[1] http://www.dreampie.org/
I am really looking forward to an improved IDLE. If anyone is interested in contributing to the project (it is written in python), here's a link: https://docs.python.org/devguide/
I have found memories of playing around in IDLE while reading through How to Think Like a Computer Scientist, back in 2003/4.
http://www.greenteapress.com/thinkpython/html/index.html
http://www.greenteapress.com/thinkpython/html/index.html
My mom recently dug out my printed copy of that when I was learning Python during that time. For the past few months, I've been helping one of my friends in a Python based CS class (using 2.x, I think). I'm not sure how useful that hard copy would be.
Tk is just too old and bad. It doesn't support Unicode rendering properly of a lot of characters and lacks a lot of features of any modern GUI toolkit like Qt or GTK.
True... but the crazy thing is the other options aren't hugely better. GTK has poor OSX support, while QT is massive and the bindings situation is still unclear - it's workable for building an app, but would you want to have it included in the default install? Kivy is neat but comparatively immature and doesn't have native theming. WxWidgets can look good but doesn't seem to have Python3 support.
I was really surprised by this actually - I wanted to create some simple GUI apps and assumed there would be something clean, small, and modern to replace TK... but nope. And all the documentation (including for python tk) is pretty terrible. The most realistic suggestion I've seen is... write you GUI in HTML and Javascript and use python for the backend server. Not a great situation when the best way to write a good looking GUI for Python is basically not to use Python...
I was really surprised by this actually - I wanted to create some simple GUI apps and assumed there would be something clean, small, and modern to replace TK... but nope. And all the documentation (including for python tk) is pretty terrible. The most realistic suggestion I've seen is... write you GUI in HTML and Javascript and use python for the backend server. Not a great situation when the best way to write a good looking GUI for Python is basically not to use Python...
A Qt IDE would be fine. Sure it is rather large - something like 30 MB unzipped for a "Hello world" using QML, though 20 MB of that is Unicode data which can be cut down, and non-QML apps are smaller. But it's much nicer than Qt.
The IDE doesn't have to be written in Python (e.g. PyCharm isn't and that is probably the best Python IDE available at the moment).
The IDE doesn't have to be written in Python (e.g. PyCharm isn't and that is probably the best Python IDE available at the moment).
> while QT is massive and the bindings situation is still unclear - it's workable for building an app, but would you want to have it included in the default install?
Qt's like < 50 M. We aren't living in 1995. It's bindings aren't just "workable"; they are pretty good.
Qt's like < 50 M. We aren't living in 1995. It's bindings aren't just "workable"; they are pretty good.
That matches my experiences when I was looking at desktop GUI toolkits for another project. I understand it though given most things are web or mobile these days.
A recent poll I had on the TkDocs site showed documentation is definitely the big issue for what people are trying to accomplish with Tk.
A recent poll I had on the TkDocs site showed documentation is definitely the big issue for what people are trying to accomplish with Tk.
https://github.com/pybee/toga
IMHO, it's rather amazing, though it needs to be developed further, to support more widgets, remove bugs, etc. Sadly it did not gain much traction after release. Maybe due to not comprehensive documentation and few nasty bugs in the beginning.
I would give this library a go if I would be developing GUI application in python, though apart making few exercises, I have not used it a lot.
Major pros, that it's in python, so debugging is easy, and what is not covered with documentation, can be uncovered also. Another thing you can simply install it with pip.
IMHO, it's rather amazing, though it needs to be developed further, to support more widgets, remove bugs, etc. Sadly it did not gain much traction after release. Maybe due to not comprehensive documentation and few nasty bugs in the beginning.
I would give this library a go if I would be developing GUI application in python, though apart making few exercises, I have not used it a lot.
Major pros, that it's in python, so debugging is easy, and what is not covered with documentation, can be uncovered also. Another thing you can simply install it with pip.
>GTK has poor OSX support
Is it really that bad ?
I was really impressed the last time I did GTK+ (was a linux app small content pipeline frontend for designers) at how fast I got things done, the docs were simple and to the point [1], Glade was buggy but still usable (I had to reload after some time because it would get progressively slower as I would add/remove elements - probably a leak somewhere) I got an app with complex tree view/table/filtering etc. running within two days from 0 previous GTK+ experience.
I liked that it was a straight GUI toolkit - reminded me of VB - just create GUI elements with RAD tool and hook up callbacks in good old python - no fancy MVC, IOT learning QML and w/e. - exactly the kind of thing that lets you do apps of this size fast IMO.
[1] https://python-gtk-3-tutorial.readthedocs.org/en/latest/
Is it really that bad ?
I was really impressed the last time I did GTK+ (was a linux app small content pipeline frontend for designers) at how fast I got things done, the docs were simple and to the point [1], Glade was buggy but still usable (I had to reload after some time because it would get progressively slower as I would add/remove elements - probably a leak somewhere) I got an app with complex tree view/table/filtering etc. running within two days from 0 previous GTK+ experience.
I liked that it was a straight GUI toolkit - reminded me of VB - just create GUI elements with RAD tool and hook up callbacks in good old python - no fancy MVC, IOT learning QML and w/e. - exactly the kind of thing that lets you do apps of this size fast IMO.
[1] https://python-gtk-3-tutorial.readthedocs.org/en/latest/
From what I could see, the Quartz backend isn't complete, and generally Mac doesn't seem to be a high priority. Some apps like Inkscape still require to install X11 for mac (which is slow, and makes for a very clunky ux), except for experimental builds with GTK native. In short, not really a plug-and-play experience.
I think Tk is entirely reasonable for the types of "utility" applications that people are primarily using it for; nobody is going to start writing a flashy new cutting edge app in it today.
For those with legacy code or other constraints where it makes sense, the TkDocs site is all about getting the most out of Tk by documenting the newer pieces that people likely haven't seen.
IDLE itself is in that category of using Tk by constraint. There have been multiple forks of it, sometimes using alternate GUI toolkits. But for it to stay as part of the Python standard library, it has to only depend on other things that are part of the standard library. Which for GUI stuff, means Tkinter. And having it built into Python is a very big deal for a lot of people teaching Python, which is the main target audience.
For those with legacy code or other constraints where it makes sense, the TkDocs site is all about getting the most out of Tk by documenting the newer pieces that people likely haven't seen.
IDLE itself is in that category of using Tk by constraint. There have been multiple forks of it, sometimes using alternate GUI toolkits. But for it to stay as part of the Python standard library, it has to only depend on other things that are part of the standard library. Which for GUI stuff, means Tkinter. And having it built into Python is a very big deal for a lot of people teaching Python, which is the main target audience.
Tk is not just "bad"; putting lots of text into Tk freezes it, lack of Unicode support, multiple modern widgets are missing.
It has the advantage of being simple. As other commenters have pointed out, there's not really a good, simple, modern, cross-platform GUI library with Python bindings. As you can observe from how slick Jupyter is getting in comparison, we've almost given up on improving native GUI toolkits in favor of using the browser. At least Tk doesn't force you to use the Motif widgets any more!
Are you forgetting about PyQt and PySide? If they don't meet the requirements for "good, simple, modern, cross-platform GUI library," then I'm hard pressed to think of a library or binding for any language that will.
I guess I could see a sticking point on "simple" but IMO it's significantly easier to create a GUI using PyQt than it would be to mess with web servers and HTML to create a web based UI.
I guess I could see a sticking point on "simple" but IMO it's significantly easier to create a GUI using PyQt than it would be to mess with web servers and HTML to create a web based UI.
Exactly the opposite --- I work with Qt in Python, and I've used both PyQt and PySide. I assure you it's not simple. Not that that's bad. It's a flexible and powerful tool. But using it doesn't feel like Python. It feels like C++ with Python syntax. No surprise, since Qt is written in C++.
You've got a point in that web-based UIs aren't any simpler. Jupyter is a project of impressive sophistication and hard work by all involved. Really what I'm complaining about is that the move toward web-based UI has starved native GUI toolkits of interest.
You've got a point in that web-based UIs aren't any simpler. Jupyter is a project of impressive sophistication and hard work by all involved. Really what I'm complaining about is that the move toward web-based UI has starved native GUI toolkits of interest.
> I assure you it's not simple.
I have to disagree. I've written GUIs in Qt/C++, PyQt, MFC (a long time ago), Perl/Tk, and even ltk/Common Lisp, and PyQt is the easiest of them all. There's definitely some C++ showing through in spots, but it's well hidden in most situations.
> Really what I'm complaining about is that the move toward web-based UI has starved native GUI toolkits of interest.
I have to agree with that. Most languages are lucky to have any native GUI toolkit bindings at all.
I have to disagree. I've written GUIs in Qt/C++, PyQt, MFC (a long time ago), Perl/Tk, and even ltk/Common Lisp, and PyQt is the easiest of them all. There's definitely some C++ showing through in spots, but it's well hidden in most situations.
> Really what I'm complaining about is that the move toward web-based UI has starved native GUI toolkits of interest.
I have to agree with that. Most languages are lucky to have any native GUI toolkit bindings at all.
IMO PyQt is pretty much like Python; the C++ parts show up in places but otherwise it's WAY simpler than Tk's complexity to do even basic stuff and horrible themeing on Linux. I used Tk a bit once; the Tcl parts show up quite a bit and it's generally very hard to use compared to Qt Designer or any other modern toolkit's tools.
"Tk is just too old and bad."
Tend to agree, funny thing though, I can use it on various versions of Win/Mac/Lin OS. The secret to Python IDLE is it just works as predicted since it came out. A clever choice of GUI.
Tend to agree, funny thing though, I can use it on various versions of Win/Mac/Lin OS. The secret to Python IDLE is it just works as predicted since it came out. A clever choice of GUI.
In the meanwhile I use Python Tools for Visual Studio: https://www.visualstudio.com/en-us/features/python-vs.aspx
Discovered this the other day, it's pretty decent imo.
Have you got python itself running in a separate process so it can't stop IDLE ?
The separate process stuff has been in there for a very long time. There is still an option to run as a single process but it has long been deprecated (and hopefully disappearing soon too).
[deleted]
Wondering if an optional file list/tree could be on the left in window integration, similar to most other modern editors?
Other than that, all looks good!
Other than that, all looks good!
High-quality corporate training hinges on maximizing student engagement. This typically means having students spend time in class writing programs. (In one four day class, I've had students write >20 programs.)
IDLE is a surprisingly good tool for this.
It's cross-platform and in the standard library. It postpones questions about which is the best editor/IDE. It avoids the tab/spaces problems. In fact, it's just about the simplest tool for teaching interactive development (i.e., coding with access to a REPL.) (I should note that this style of programming is distinct from how quants and data scientists work: they write more analyses than programs/scripts. When doing corporate training for quants and data scientists, Jupyter Notebook is the only way to go.)
By the end of the class, most students are pretty tired of using IDLE. It's not a very good editor; only barely better than Notepad. As the article's screenshots show, it just looks ugly. It's not even close in functionality to an IDE or a `vim`/`emacs`+plugins. The REPL is extremely clumsy to use in practice (especially compared to `bpython` or `ipython`.) In fact, I would be shocked if anyone actually uses IDLE as part of their regular job.
That said, it's a great teaching tool, and I'm glad to see someone putting effort into improving it.