Our Experiences Switching to Python
In response to a question about what it’s been like switching to Python as a first-year programming language, Paul Gries wrote the following. It might be of interest to other instructors who are thinking of changing over.
And in related news, we’re compiling errata and solutions to even-numbered exercises for a fresh printing of Practical Programming. We’re pleased with how well it’s doing; in particular, we’ve been pleasantly surprised by the number of inquiries we’ve had from people who are home schooling. If you have questions, suggestions, or experiences to share, we’d love to hear from you.
The switch to Python was quite smooth, except for the following items:
- We decided to write a textbook because we didn’t think we could live with the options at the time.
- We decided to use Mark Guzdial’s excellent multimedia approach, but ended up almost completely rewriting his media module to use standard Python instead of Jython and had many issues with his development environment. Mark had a proof of concept that we worked from, but it used Java naming conventions and since it was designed and written by undergrads it needed a lot of cleaning up. You can find installation instructions for all of the packages that we use at . A team of about 4 people worked roughly 1 day a week throughout the summer in 2007 to put together the lectures, assignments, labs, and tests, and we’ve been refining that since then.
We love most of Python, especially the clean, readable, minimal syntax. However, there are several Python gotchas, and we were bitten by almost all of them. Here are some of the major ones that confused either students or instructors:
- There are no good GUI packages; Swing was at least teachable, but Tkinter has lots of warts and none of the others (e.g., wxPython, PyQt) seem to be usable on all three major OSes. We’ve dropped Tkinter this fall in favour of EasyGUI, which has major limitations but is much more teachable.
- It’s hard to know when to stop. List comprehensions, for example, are really cool and natural, but they make a surprising number of problems too easy and allow students to avoid writing loops. We show them toward the end of our intro course but don’t require the students to use them.
- Aliasing is surprising and comes up naturally and even accidentally, especially in lists. This is not necessarily Python-specific, but it sure comes up more in Python than it did in Java.
- Default values for parameters are created once. Students (and some instructors) hate this.
- Simple classes are harder to teach than in Java. Also, “self” confuses a large subset of the students. Since dictionaries are so accessible they do whatever they can to avoid using and understanding classes.
- Global scope is hard to explain: it’s actually module scope and not global, and in the three examples below there are different behaviours; the last example in particular really confuses students. They do all of these things naturally, so we can’t prevent them getting confused.
# Example 1 i = 1 def f(): print i f() print i# Example 2 i = 1 def g(): i = 2 print i g() print i# Example 3 i = 1 def h(): print i i = 2 print i h() print i - More scope: nested functions baffle students.
On the positive side, some students LOVE putting functions into dictionaries and getting rid of huge if/else statements. They also find passing functions as parameters to be natural; we introduce this idea to write a timing function that returns how long its argument runs. This is a lovely thing to do when we get to searching and sorting.
In CS2, we’re struggling with how much information hiding to do; we’re conflicted about whether __var plus set_ and get_ helpers is what we should do or if we should get into properties. We’re leaning toward the former, but we’re not certain.
“Since dictionaries are so
accessible they do whatever they can to avoid using and understanding
classes.”
That “problem” exists everywhere I’ve been. Worse, it’s sometimes hard to get people to give up tuple or list pairs for dictionaries.
The nice thing about Python is that it allows you to solve problems right away, even if you’re not using the best tools (or writing the best code). I avoided the whole object thing for a long time myself, mainly because I was turned off by Java’s “you have to construct a class to do anything” approach.
Now that I’m working a little more with Java, I can see why it’s preferred in a lot of business environments. What got me to use objects in Python as a newb was scale. The problems I was working on (huge datasets with a lot of attributes) forced me to take the object plunge. It’s tough to get to that point in one introductory semester.
My $0.02.
Carl T.
> we’re conflicted about whether __var plus set_ and get_ helpers is what we should do
Definitely not. For starters, the `__` prefix isn’t for information hiding it’s been introduced to avoid naming conflicts during inheritance. Using it to “hide” variables is un-pythonic.
Second, why use get_ and set_ when properties would do? And do you really care that much about information hiding in CS2? Is it in the context of interface and API design or “just ’cause”?
I really wouldn’t teach __name for information hiding, it isn’t what it’s there for and it doesn’t work! By all means teach the single underscore (_name) *convention* though.
Properties over getters and setters every time – much more pythonic. Even as a step on the path I would resist teaching techniques that are actually bad practise.
Great post by the way. Do you teach the mutable vs immutable early on? This seems to me the best way of addressing the aliasing and also function default arguments gotchas.
“List comprehensions, for example,
are really cool and natural, but they make a surprising number of
problems too easy and allow students to avoid writing loops.”
One of the nicest comments about Python I’ve ever read.
“”"It’s hard to know when to stop. List comprehensions, for example,
are really cool and natural, but they make a surprising number of
problems too easy and allow students to avoid writing loops.
“”"
This sounds like something to embrace. Introduce loops in the very beginning, show students how to implement map() or a LC using a loop, then don’t require explicit loops any more.
I find PyQt quite usable on all of the Big Three platforms. What do you see as problematic?
These days, why teach form-GUI programming at all? Desktop apps are built in interface builders, or they’re games. Web GUIs are the common case now, and they’re built in totally different ways.
Noo! Don’t use the stupid double underscore! Never! Ever! They have a very particular use, and using them for anything else (ie, information hiding) is no good.
Single underscore is fine – in Python-speak, it’s analogous to protected in Java. Double underscore is equivalent to Java’s “private”, which is almost never “what you actually want”.
IMO, it should be noted that the double underscore magic exists, but should not be used unless you’ve got a really, really good reason.
Also, IMO, go for properties: getters/setters aren’t incredibly “pythonic”, and encourage the writing of “busy code”. With properties, you can start out using variables, then when you realize you need more logic, you can replace them with with properties.
I mostly agree with David about __vars. If you are going to teach CS using a dynamic language, I think you should teach dynamic idioms. Enforced information hiding is perhaps useful in other languages with more segfaults.
Interfaces, perhaps via ABCs, might be a better way to teach the good information hiding practices that are general across languages.
The three scope examples, as well as some of the other problems mentioned, and others I’ve encountered students having, suggest that Python isn’t as “readable” as claimed, unless “readable” doesn’t include “with the correct meaning”.
@Gary: do you pretend to understand a language before learning it? Python is (even in the cases mentioned) as readable as possible, but not more.
Heck, since recent versions, the error printed when calling h() is a very understandable
Traceback (most recent call last):
File “”, line 1, in
File “”, line 2, in h
UnboundLocalError: local variable ‘i’ referenced before assignment
Robert Kern asks: “I find PyQt quite usable on all of the Big Three platforms. What do you see as problematic?”
One issue we’re dealing with is that a significant number (20%, perhaps?) of the students in our intro course are not planning to major in computer science, and they are not technically savvy. Heck, the majority of our students have never programmed before. Every extra step can cause a lot of pain.
So: the main issue we have with PyQt is with the installation, at least on OS X:
http://www.oak-tree.us/blog/index.php/2009/05/12/pyqt-mac
Most students want to work on their own computers, but asking new programmers to follow those instructions would lead to mass confusion, and a mass exodus from the course when they can’t get it to work.
I recommend pyGTK for GUI programing , its easy to develop and works on the 3 plataforms