I am a big fan of the programming language Python, and was one of the first people (along with my colleagues) to write about using Python in computer science education. That year, 2003, was probably too early for many schools to even consider using Python as a language for the introductory CS courses (which we call CS1), because they were just switching from C++ to Java.
Since that time, we have fully embraced Python in our courses. Personally, I have worked for the past 8 years to make using Python easy and accessible for all students, especially those from non-traditional backgrounds and underrepresented groups. In the early years, we used the de facto standard editor for Python, called IDLE. IDLE has always had issues, but perhaps not more than the entire Python ecosystem itself. In the end, we ended up writing our own editor, and, in fact, creating our own entire “stack” of software—we package everything needed to do cool stuff, including graphics, music, text-to-speech, robotics, and more.
Python’s motto is “batteries included” because it has an extensive standard library that allows much functionality without having to download additional modules. But, if you stray from the standard library, then things get hairy quickly. Take, for example, text-to-speech. This is the functionality that allows you to take text and produce the sound waves on your speaker of a human-sounding voice. You know, like Siri or Her. Such functionality is often implemented as a low-level library, often written in C. These libraries often need to be compiled for each type of computer (Mac/Windows/Linux * 32bits/64bits * version). On top of the low-level libraries there are often “wrappers” that allow them to be used from Python. Trying to make a simple Python interface for students to use on whatever computer they have turned into a impossible compatibility task—there were just too many variables changing too quickly.
In the end, we created a system, called Calico, that contains all of the bits necessary, with very few dependencies on low-level libraries, and no wrappers. I’ll be writing more about Calico in the future.
In a recent post on the idle-dev mailing list, a link was posted to a video by Jessica McKellar on “The Future of Python“. Jessica points out many issues with Python, and makes many good suggestions, and I agree with most of her main points. But, I don’t think she goes far enough. For example, she says (around the 10 minute mark) that part of the problem with IDLE on Windows is that there aren’t enough developers that are invested in the problem. I would say that there aren’t enough IDLE (and Python) developers that actually have to wrestle with using Python in the classroom.
How do you install Python (say on the Mac or Windows), and run IDLE? How do you make Python say “hello, world” out of your speakers? How do you make a window and draw a shape? It is too complicated to get to the point where you can do these things.
- IDLE needs its own Guido. Someone needs to make hard decisions to make IDLE useful for beginners. IDLE should focus on doing intro CS (at all levels) well. It should have an easy-to-use stepper/debugger. This IDLE-Guido should be in the classroom everyday, and be a visionary.
- There needs to be a complete Python environment (with easy access to graphics, audio, devices) ready for easy download and install, with IDLE (or a new editor) prominently visible.
Until we tackle these two issues, look for future “Future of Python” suggestions that aren’t that different from past ones.