I was initially a bit put off by the Python indentation approach (I was a grammar guy… and got used to parsing braces and parens, and didn’t like the idea of white space having so much meaning), but I soon came to love it. Eventually I came to apply one of my favorite computer science sayings to Python as an endorsement to their indentation blocking approach: “The fundamental evil in computer science is the replication of code or data.” In almost all languages I had previously worked, the indentation of code had always been a critical PART of program nesting structure (at least for the reader). As I read and wrote more Python, its use of indentation as the ONLY way to specify blocks began to look better and better. All the silly bugs related to indentation errors (misleading the human reader) were gone in Python. The redundant use in other languages of braces AS WELL AS indentation (the former to help the parser, and the latter to help the human reader) was an effective duplication of the author’s intent. That duplication in other languages, a fundamental original sin, was missing in Python. It was cool! ;-)Yes, indeed. Python is cool. :-)
Monday, June 05, 2006
Praise for Python
Sometimes, I come accross something which I really wish I could have written. Usually, I just smile, try to commit it to memory, and move on. This time, I have to quote what Jim Roskind wrote on Guido's blog:
Sunday, June 04, 2006
RUR-PLE video
The kind folks from ShowMeDo had contacted me and suggested I make a demonstration video for RUR-PLE. I'm happy to announce that this has been done, and that the video now appears on the ShowMeDo website. The link to this demonstration video can be found on the right hand side side-bar for this blog. The sound quality is not all that good, but the video should give a good idea of what RUR-PLE is all about. (I will definitely need to get a better microphone for future videos, and possibly for remaking this one.)
Thursday, May 25, 2006
rur-ple bug fix for Mac and Linux users
Brad Miller uncovered a bug (hard coded windows specific path separators) in version 0.9.8.2 of rur-ple. Version 0.9.8.3 has been uploaded with required changes. Apologies to Linux and Mac users.
Summer of Code 2006
For a second year in a row, Google is paying hundreds of students to spend their summer contributing to open source projects. This is known as Summer of Code 2006. The Python Software Foundation is a mentoring organisation that is the beneficiary of 25 Summer of Code projects. Continuing on my streak of luck with Python, I am mentoring Johannes Woolard, a promising student whose project was accepted in this Summer of Code competition. Johannes has a blog, and has already started working on his project. Within the span of a day or two, he has already removed the CherryPy dependency of Crunchy Frog, which was one of my longer-term objective - but something I didn't know how to do. Kudos to Johannes!
Tuesday, May 23, 2006
Rur-ple 0.9.8.2 released
I implemented in rur-ple the "auto-indent" feature that was added to Lightning Compiler. This should be more user-friendly for beginners. I also fixed a bug that was introduced when I improved the highlighting method - it was no longer possible to run programs where robots were introduced by an instruction [e.g.
Reeborg = UsedRobot()] in an otherwise empty world.
Lightning 2.1
Thanks to Milan Melena, who left a code sample on this blog, Lightning 2.1 has been released, with added auto-indent and quick fold/unfold. Next, I'll have to consider added auto-indent to rur-ple.
Monday, May 22, 2006
Rur-ple: getting closer to 1.0
Rur-ple is getting ever closer to version 1.0. I have to finish about 10 new lessons to get to version 0.9.9 after which I will do a final cleanup of the code for the 1.0 release candidate. The current version (released today) is 0.9.8.1.
Since the last release, I made two changes that should be helpful for students. The first one has been to use a scintilla feature to indicate white spaces with tiny dots as indicated in the picture below.

This should help locate problems related to blank lines with a number of spaces that does not match the indentation level; this had apparently been a problem for some students.
The second change is more significant. When I started working on rur-ple, I wanted to be able to step through the code and highlight the line of code being executed. I managed to do this only partially through a kludge.
The first step was to take the user code and add some line number information using the Python module tokenize and some complicated processing. For example, the code shown above might be re-written as follows:
I would then call exec to execute the processed code, leaving the unprocessed one displayed in the editor window. Each time a basic instruction (like move, turn_left, pick_beeper, put_beeper) was executed, the graphical display would be updated and the corresponding line of code in the editor was highlighted. When I came up with this solution, I had only been programming with Python for a few months and thought it was rather clever.
Unfortunately it was not possible, using this method, to highlight every line being executed: only those with one of the four basic robot instructions.

The new version makes use of the Python method sys.trace to follow the execution. It is much simpler than the old version (5 lines of code instead of 33) and works much better, as can be seen on the picture on the left. It has not yet been field tested but Andy Judkis's students should do just that in the coming week.
Since the last release, I made two changes that should be helpful for students. The first one has been to use a scintilla feature to indicate white spaces with tiny dots as indicated in the picture below.

This should help locate problems related to blank lines with a number of spaces that does not match the indentation level; this had apparently been a problem for some students.
The second change is more significant. When I started working on rur-ple, I wanted to be able to step through the code and highlight the line of code being executed. I managed to do this only partially through a kludge.
The first step was to take the user code and add some line number information using the Python module tokenize and some complicated processing. For example, the code shown above might be re-written as follows:
def follow_right_wall():
....linenumber = 20
....if right_is_clear():
........linenumber = 21
........turn_right()
........linenumber = 22
........move()
........linenumber = 23
....elif front_is_clear():
........linenumber = 24
........move()
........linenumber = 25
....else:
........linenumber = 26
........turn_left()
........linenumber = 27
I would then call exec to execute the processed code, leaving the unprocessed one displayed in the editor window. Each time a basic instruction (like move, turn_left, pick_beeper, put_beeper) was executed, the graphical display would be updated and the corresponding line of code in the editor was highlighted. When I came up with this solution, I had only been programming with Python for a few months and thought it was rather clever.
Unfortunately it was not possible, using this method, to highlight every line being executed: only those with one of the four basic robot instructions.

The new version makes use of the Python method sys.trace to follow the execution. It is much simpler than the old version (5 lines of code instead of 33) and works much better, as can be seen on the picture on the left. It has not yet been field tested but Andy Judkis's students should do just that in the coming week.
Subscribe to:
Posts (Atom)