The Python Papers

Volume 2, Issue 2

pythonpapers.org

Journal Information

The Python Papers

ISSN: 1834-3147

Editors

Tennessee Leeuwenburg

Maurice Ling

Richard Jones

Stephanie Chong

Referencing Information

Articles from this edition of this journal may be referenced as follows:

Author, “Title” (2007) The Python Papers, Volume N, Issue M, pp. m:n

e.g. Maurice Ling, “Firebird Database Backup by Serialized Database Table Dump” (2007) The Python Papers, Volume 2, Issue 1, pp. 7:15.

Copyright Statement

© Copyright 2007 The Python Papers and the individual authors

This work is copyright under the Creative Commons 2.5 license subject to Attribution, Noncommercial and Share-Alike conditions. The full legal code may be found at http://creativecommons.org/licenses/by-ncsa/2.1/au/

The Python Papers was first published in 2006 in Melbourne, Australia.

Referees

The Python Papers

Volume Two, Issue Two : May 2007

In this Edition:

Articles and Editorials:

Bumper edition released, summary of articles, notes on the readership, Wing IDE giveaway winner announced and a call for more volunteers to sit on the editorial board.

Christopher Arndt and Rex Turnbull

What do you do, if you're new in town, a jobless software developer and a Python fan? Right, you set up a local Python User Group. That's at least how it worked out for me when, last fall, I suggested a meeting of Python enthusiasts at a local Linux fair and nine other like-minded people showed up on the spot. Thus the Python User Group Cologne, quickly afterwards dubbed *pyCologne*, was born and we've had regular meetings every month since then.

Michael Tobis

If learning is about information, then surely education will change somewhat under the influence of pervasive information technology.

This is an exciting time for those of us who believe that software development in general, and Python in particular, has a role in general education...It seems like a good time to take stock of the entire educational programming landscape and Python's role in it.

Tennessee Leeuwenburg

Horst Jens, one of our readers, wrote in to let us know of a great project he is involved with: teaching Python to primary school students. They have posted some video material and we wanted to let our readers know too!

Brett Canon

I should begin with the statement that the trip was fantastic! It was probably the best PyCon for me personally as well as the best one in terms of content...It was also the largest with 594 people in attendance which is amazing considering that is a 43% growth rate compared to last year!

Chris Seickel

MPD WebAMP provides a browser based interface to control music playback via MPD. It includes it's own CherryPy web server and provides a single page application with the features and interface one would expect from a standard desktop application. Although it is not unique in it's use of AJAX or it's use of a python based web server, it is unique in that it is a completely asynchronous interface which looks and behaves like an application rather than a web interface.

Paul Boddie, David Boddie and other EuroPython2007 Wiki Contributors

Now in its sixth year, EuroPython - known more formally as the European Python and Zope conference - moves on once again. Upholding the EuroPython tradition of helping European Python users and others to learn more about Python and its uses, the conference is also a great opportunity to become acquainted with different parts of the European continent. This year, EuroPython descends upon Vilnius, the capital city of Lithuania, calling it home from Monday 9th July until Wednesday 11th July 2007. Although the programme for this year's conference has yet to be finalised, reports and materials from last year's highly successful event may be persuasive for those considering making EuroPython 2007 part of their schedule.

A list of upcoming Python events.

Peer Reviewed Submissions:

Alex Holkner

One of the new features of Python 2.5 is the introduction of ctypes as a standard library module. At the simplest level, ctypes adds the standard C types to Python: signed and unsigned bytes, shorts, ints and longs; as well as structs, unions, pointers and functions. At run-time it can load a shared library (DLL) and import its symbols, allowing a Python application to make function calls into the library without any special preparation. ctypes can be used to wrap native libraries in place of interface generators such as SWIG, to manipulate memory and Python objects at the lowest level, and to prototype application development in other languages.

Ben Askins and Alan Green

Ruby on Rails is the dominant web programming framework for Ruby, and, even outside the Ruby community, is considered the epitome of the latest generation of high-productivity, open source web development tools. Django is one of many competing web development frameworks for Python.

In this paper, Askins and Green compare the two frameworks from the point of view of a developer attempting to choose one of the two frameworks for a new project.

The Python Papers review policy covers both industry and peer-reviewed articles. This is included for academic purposes.

Letter from the Editor

Tennessee Leeuwenburg

In this issue, we present a number of industry articles. These include Python in Education and MPD WebAMP, as well a great insight into Python in Germany, a wrap-up of PyCon 2007, a preview of EuroPython 2007 and a look at some great videos prepared by primary school students. Our peer-reviewed section reproduces two selected papers which were originally presented at the Open Source Developer's Conference 2006¹ (Melbourne, Australia).

Illustration 1: World map showing the last 100 visitors to pythonpapers.org on 20 May 2007

I'd like to express how pleased I am that we have been able to engage so many distinct groups. I am not aware of any detailed investigation of the use of Python internationally, so this may represent unique information on the spread of Python around the planet. If anyone from Japan, Singapore, Taiwan or Israel would like to contact The Python Papers, we would love to hear from you as we do not currently have any contacts from these countries. Indeed, we would love to hear from anyone who would like to be involved with this journal.

Another exciting discovery has been the audio transcript of The Python Papers which is being distributed by scribd. The previous edition is currently available from http://www.scribd.com/doc/6424/The-Python-Papers. From here, the journal may be viewed as a PDF online, as MS Word, plain text or a text-to-speech rendering may be downloaded as an MP3 file. Having listened to this audio, I must congratulate that site on its great quality. The only real drawback is that the opening pages of the magazine, the table of contents and the code snippets can seem repetitive. The article text, however, comes across wonderfully.

There have been significant growing pains involved in the development of The Python Papers. The editorial board, especially yours truly, has been struggling to achieve all the goals that would ideally be met. We would love to hear from anyone who would be happy to give us a hand, whatever your area of expertise or interest may be. In particular, we would love to hear from one or more people who are happy to take on the management of our website. This would include not just the technical aspects of creating a blog (working with the other editors to agree on a front page design and other “getting started” issues) but also ongoing maintenance of the website, including helping to create new documents as needed, respond to web queries etc.

There are a number of other roles which a committed individual could adopt and thereby provide enormous assistance. A representative for each country would be an enormous help, especially in collating contact and web presence information on local Python User Groups and events. It is difficult to keep abreast of the variety of activity around the world. Local assistance here would be a huge help.

Contribute and win – prizewinner announced!

Congratulations to Chris Seickel! He is the lucky winner of the “contribute and win” competition. He will receive a 3-OS license for Wing IDE, a fantastic development environment created by Wingware³.

Introducing The Team

Tennessee Leeuwenburg – Editor-in-Chief

Tennessee Leeuwenburg is a software developer working at the Australian Bureau of Meteorology on automatic text generation of weather forecasts. Prior to this he spent time working on meteorological data transfer standards in the form of the OpenDAP database system.

Maurice Ling – Associate Editor

Maurice Ling is a PhD candidate in the department of Zoology of The University of Melbourne working on text analysis of biological literature for the purpose of understanding hormone interactions in the mouse mammary cell.

Richard Jones – Associate Editor

Richard is Blue Box Device's lead OpenGL developer with over 10 years of broad experience working with multiple languages and tools in web-based management systems, data archive, meta-data systems, computer graphics, business systems, e-commerce and communications. He also runs the bi-annual PyWeek Game Programming Challenge and is involved with the organisation of the Open Source Developer's Conference in Melbourne, Australia.

Stephanie Chong – Associate Editor

Stephanie is currently studying Arts/Law at The University of Melbourne.

Contacting The Python Papers

The editors may be contacted via email at: editor@pythonpapers.org. We are always happy to receive feedback, suggestions for improvement and ideas for future articles and topics.

Contribute to The Python Papers

If you would like to contribute an opinion piece, an article, participate in an interview or submit a paper for review and publication, please don't hesitate to contact us at editor@pythonpapers.org.

Python User Group Highlights: Introducing pyCologne

Christopher Arndt and Rex Turnbull

setup(name='pyCologne', description='Python User Group Köln')

What do you do, if you're new in town, a jobless software developer and a Python fan? Right, you set up a local Python User Group. That's at least how it worked out for me when, last fall, I suggested a meeting of Python enthusiasts at a local Linux fair and nine other like-minded people showed up on the spot. Thus the Python User Group Cologne, quickly afterwards dubbed *pyCologne*, was born and we've had regular meetings every month since then.

For those readers unfamiliar with Germany, the city of Cologne (the proper German name is "Köln"), is by number of inhabitants the fourth biggest city in Germany, with just over one million citizens. It has a strong industrial tradition, being to the south-west of the highly industrialized and populated area of the "Ruhrgebiet". Today it has a strong footing in the tertiary sector, with the media (tv) and design industry being major sources of employment. I'll give you some more information about Cologne and its sights later, let me tell you something more about our group first.

def pyCologne():

Given Cologne's geek-friendly environment and a large university, it is perhaps not surprising that our group's meetings were able to attract 15-18 people each time so far and that there are about 50 subscriptions to our mailing list⁴. We have no explicit membership but there is a "core" of about 8-10 people who show up at every meeting. Since the group is still rather young, it remains to be seen how things will develop in future.

As things stand now, pyCologne meets on the second Wednesday every month. Our meetings begin with a "business" part with one or two presentations or discussions and last about two hours as the content always leads to more discussions. After the official part, we usually head off to a pub for food, drinks, and friendly conversation.

PyCologne User Group Members

x.get_interests() for x in pyCologne.items()

There are indeed plenty of interesting, Python-related topics to talk about, since the members of our group use Python for an astonishingly wide area of applications. Some are directly involved in developing software professionally that makes use of Python in one way or another, others just use it as a tool for internal purposes. I'll mention just a few fields where our members employ Python (I could easily list a dozen more):

• Grid-computing (for example in the aerospace industry)

• Game scripting

• Web development

• Data-mining

• Financial transaction systems in the banking business

• Zope and Plone

• Personal tools and system administration

There are also a few of us who have little or no programming experience and want to find out more. Though it is true that Python is still relatively little known in Germany, interest in it is developing fast. The past months have seen the founding of several other German PUGs besides pyCologne. Some well-established projects from the Python world were also founded by German developers, for example the MoinMoin wiki system⁵ (which also drives the official Python wiki⁶) and Stackless Python⁷, an implementation of the Python interpreter that doesn't use a global interpreter lock (GIL) and features high-performance, concurrent computing mechanisms.

Cologne.__doc__

Night-time view accross the Rhine towards the old town and the Dom. http://commons.wikimedia.org/wiki/
Image:Koeln_Nachtaufnahme.jpg, GNU FDL

Though much of the city center of Cologne was destroyed in World War II – a fate that Cologne shares with most German cities - a good part of the old town was preserved or rebuilt and is now a favourite tourist haunt. The inner town is dominated by Cologne's landmark -- the Dom (Cathedral) with its twin spires, work on which was begun in 1248 and finally finished in 1880. It is the tallest gothic church in the world and can be seen for miles. The city's citizens are rightly proud of this historic building.

Kölsch, the local beer variety, can be found in all restaurants and bars in and around Cologne. It is a clear, yellow-colored, top-fermenting beer and is served in small beaker-like glasses, where the beer stays cold and fresh. When going out for a drink in Cologne, it is easy to rub shoulders and have a chit-chat with the locals, who are said to have a friendly, out-going nature.

finally:

Meeting many other people who like Python is a fun and interesting experience and we are always interested in hearing from others sharing our interest in all things Pythonic. Whether you live in the region or you are just staying here on a business or holiday trip, why don't you check out our website on the German Python wiki⁸ [6]_ and see when we have our next meeting? The website also has slides and examples from the presentations given at past meetings and some more photographs. If you have your own Python user group and you want to share experiences, we would love to hear from you as well, wherever you are!

And, by the way, in case you wondered, thanks to the many contacts made via our group, I am now working as a freelancing Python software developer...

To find more information, or to contact members of PyCologne, visit http://wiki.python.de/pyCologne

Python in Education

Michael Tobis

SALIENT QUOTATIONS

"Should the computer program the kid, or should the kid program the computer?"
- Seymour Papert

"We want to explore the notion that virtually everybody can obtain some level of computer programming skills in school, just as they can learn how to read and write."
- Guido van Rossum

"Python makes too much sense as a learning language to not ultimately have an effect in the education arena."
- Arthur Siegel

"If schools won't accept classes that have Python in them, then it doesn't matter how much better Python is than BASIC, the classes cannot be taught."
- Dean Nevins

PYTHON IN EDUCATION

If learning is about information, then surely education will change somewhat under the influence of pervasive information technology.

This is an exciting time for those of us who believe that software development in general, and Python in particular, has a role in general education. Three of the four keynotes at PyCon '07 involved the idea of computing as a medium for education and/or communication. Adele Goldberg talked about the frustrations of getting carefully designed computational curriculum into the public school systems. Robert "rOml" Lefkowitz talked about code as a communication medium. Finally, on a more practical note, Ivan Krstic discussed the very exciting prospects of the One Laptop Per Child project, whose modest goal is to make computing available to all children everywhere.

These discussions gave a boost to the quiet world of educational Python. It seems like a good time to take stock of the entire educational programming landscape and Python's role in it.

COMPUTER LITERACY

In the early days of computing, it became apparent that computers would become ubiquitous and part of daily life. At that time, we had little idea what shape they would take in a generation.

I recall an episode of the futuristic TV news program "The Twenty-First Century", broadcast in 1967 hosted by the renowned Walter Cronkite. It discussed the implications of home computers. A professor's family had a massive mechanical teletype (a terminal that used a typewriter mechanism rather than a CRT or LCD display) in their home. The demonstration application was, as I recall, changing the proportions in a recipe so that it served seven rather than four.

Presumably, it was a great tangle of Lisp under the hood, and awkward for the user, but it appeared that if you persevered, a recasting of your recipe (with all the quantities multiplied by 7/4 and converted to standard cooking units) loudly clanked out onto the fanfold paper. At the time, the 21st century was promoted in the media to be an almost flawless utopia, but even so one had the sense that both Cronkite and the professor's wife were struggling to express any enthusiasm for the concept of home computing.

If you think about what "computer literacy" means today in high schools, trade schools and nontechnical programs in university, though, you'll see that it amounts to recipe scaling writ large. Mass market software presents complex and often counterintuitive user interfaces, and the skill of navigating through each of them is valued and promoted. The expression "computer literacy" is taken to mean a capacity to cope with mass market application software. (If this were actually useful in schools, perhaps it would work better if the adolescents taught the faculty.)

PROGRAMMING FOR CHILDREN

Of course, we do need to be able to cope with applications. Still, there have always been two visions of computing, one as a world in which there is a very sharp distinction between producers and consumers of software, and another where the continuum is blurred.

The view of computer literacy as a continuum which includes programming was formed by the early users of computers. In those days, there were no "applications". Being a computer user amounted to being a programmer. Many of us felt that the skills we learned by wrestling with the structure and logic of a program would be applicable to many aspects of life. We felt that the advantages we were getting could be democratized. In this view, "computer literacy" was about coding, not about being able to push a mouse around and click on things effectively.

This view is succinctly summarized by Georgia Tech Professor Mark Guzdial's phrase on a blog page: "computing FOR learning (as opposed to learning ABOUT computing"⁹.

Seymour Papert (with Willy Feurzig) developed Logo¹⁰, the original “learning language” in the late 1960's. The ideas of Logo were explicitly based on developmental psychology¹¹. Papert not only claimed that remarkably young children (fourth graders, about 9 years old) could be exposed to the ideas of programming, he was successful in demonstrating this. Many subsequent teaching environments have been based on Logo, and especially on the observation that "turtle graphics" were a uniquely compelling development target for novices. (It's interesting to contemplate the fact that it was less expensive to construct a mechanical turtle than a graphic display in those days!)

Alan Kay's remarkably prescient 1971 "Dynabook" paper¹² is a remarkable exposition of the possibilities of computing from a time long before anyone actually had so much as a portable display. Kay and Papert are still with us as I write (although, unfortunately, Papert was seriously injured recently). Among their recent efforts (along with Nicholas Negroponte) is the One Laptop Per Child initiative¹³, where Python plays a key role, and which largely revives the Dynabook idea.

COMPUTING FOR NOVICES

Despite the strong advocacy of the likes of Papert and Kay, there is no consensus on whether most people can and should learn a modest amount of programming, nor what age is best to start. Still, if we can stipulate that some people will become programmers, we conclude that they have to start with some language. Is it important which language that is?

Among the most famous quotations attributed to the great computer scientist Edsger Dijkstra are critiques of teaching computer science with inappropriate languages, notably that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense" and "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." Many people have taken DIjkstra's advice to heart, and designed languages intended to expose young adult students to good practice and good theory from the beginning. Pascal and Smalltalk are probably the most successful examples.

Another effort in this direction was the ABC programming language project of Geerts, Meertens and Pemberton at Centrum voor Wiskunde en Informatica (CWI) in Holland. They list some advantages of ABC in comparison to Pascal as 1) small, intuitive syntax; 2) maps well onto design principles; 3) terseness; 4) support for refinement; 5) no declarative statements; and 6) interactive¹⁴. Along with these good ideas the CWI group had the inspiration to put the young Guido van Rossum on staff, and it is here that the Python story began.

While much of the history of the Python community remains an oral history, we do have the following quote from Guido: "Over six years ago, in December 1989, I was looking for a 'hobby' programming project that would keep me occupied during the week around Christmas. My office would be closed, but I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately: a descendant of ABC that would appeal to Unix/C hackers¹⁵." This was the origin of Python - the combination of a well designed learning language and a practical scripting language.

COMPUTER PROGRAMMING FOR EVERBODY

Once Python had attained a certain momentum, Guido van Rossum under the auspices of the Corporation for National Research Initiatives applied for and received a small grant to support a project called Computer Programming for Everybody (or CP4E), to investigate democratizing programming. The project was funded for a single year, half the anticipated duration, through the Defense Advanced Research Projects Agency¹⁶ (the same agency that funded the initial development of the internet). Guido and much of the core development team moved into the for-profit sector at about that time as well. The proposal¹⁷ lists broad objectives of developing high school and college curriculum, developing tools, and developing a user community, as well as many subcomponents of these objectives.

The motivation section¹⁸ is in the intellectual lineage of Papert and Kay:

“If we are successful, non-experts will be able use their computers and other intelligent devices much more effectively, reducing their level of frustration and increasing their productivity and work satisfaction. (New leisure possibilities will undoubtedly ensue as well!) Computer users will be able to solve their own computer problems more often, reducing the need for technical support.

Even if most users do not program regularly, a familiarity with programming and the structure of software will make them more effective users of computers. For example, when something goes wrong, they will be able to make a better mental model of the likely failure, which will allow them to fix or work around the problem. They will also be able to assess better when they can make the changes themselves and when they will need the services of an expert. They will be more able to converse with experts, since they will now share more of a common language. An analogy is obtaining basic literacy in automotive maintenance: you know enough to check your oil and add a few quarts if necessary, but you also know that you shouldn't try to change your own brakes. When the mechanic says 'your rotors are warped and you need new pads,' you understand what he is talking about.

If this effort is successful, there could be many millions, eventually billions of computer programmers, at various levels of proficiency. The effects this will have on the state of the art of software development is hard to imagine. The nature of software will change to accommodate the needs of these programmers, allowing customization through source code modifications--and personalizations will be plentiful.”

The funded CP4E project's principal achievement was developing the IDLE system. IDLE is a clean and lightwieght development environment in the tradition of the early Borland IDEs. Because of its simplicity and convenience, it remains the development platform of choice for beginners in many contexts.

Still, it must be admitted that many of the goals of CP4E remain unfulfilled to this day. The SIG that was centered on the project, while hosting many fascinating discussions, lost focus. Until recently, a fairly large number of fairly small projects were developed in and around the cluster of ideas that motivated CP4E and the edu-sig. Efforts to create a directory and a repository for this work have so far failed to reach critical mass. There appears to be a cat-herding problem, with each enthusiast having his or her own individual goals. That said, a great deal of fascinating work has been and continues to be happening, and quite a few young people have been exposed to Python as their first programming language and environment. Perhaps even more importantly, the mission of CP4E, and Python's role in it, has been an active goal for quite a few people in the intervening seven years.

The section “Further Information” at the end of this article attemps, and surely fails, to be an exhaustive list of Python related education projects. It includes projects where Python is or has been used to develop a domain specific learning language or learning tools, or where Python is used as the language of discourse in teaching programming, or in using programming to teach other topics. It is limited to resources aimed at novice programmers who are not necessarily going to become technical or computing professionals.

WHY PYTHON?

Pulling together these Python as a First Language/CP4E experiences, formalizing them, and making a case for them in educational settings, remains somewhat elusive. If we accept Dijkstra's admonitions that “a first computing language is important to the intellectual development of the student”, it seems to those of us who appreciate Python that it would be a good choice. However, it is arguably our responsibility to get beyond "we like it because it is good" for the non-Python audience.

The Python community knows what it likes and is amazingly verbose and articulate in discussing this or that programming construct, but we have never been particularly adept at explaining our vision to those who have not experienced it. In researching this article, I made some effort to get Python First [Ed – the concept of Python as the first programming language to learn] enthusiasts to explain the basis of their enthusiasm in the context of the novice programmer. I found some people who were willing to focus on certain features of the language, resembling the features of ABC described above.

I would like to venture an alternative explanation (inspired to some extent by comments from Kirby Urner and from Ian Bicking about how Python relates to object-oriented programming). That Python is arguably the best language for beginners and arguably the best main language for professionals is neither a coincidence nor a remarkable achievement. The properties that make Python uniquely powerful arise from its being codesigned as a language of learning and a language of production simultaneously and at its roots.

It's the quiet power of Python that makes it such a revelation to those of us who discover it after years of struggling with less expressive languages. I don't know if any of the core group has ever expressed what makes something Pythonic (except, perhaps, in cryptic zen terms), but I suggest it is that the power of Python is there when you need it and stays out of your way when you don't need it. Pythonic code then is code which is in keeping with this principle.

The positive consequences of this aesthetic seem to the Python devotee to be stunningly vast. Some of them reflect directly onto beginners. Consider that expert code in Python is indistinguishable from beginner code in those cases when the expert is doing something a beginner might do. The amount of unlearning required to become expert in Python is very small, and the amount of incomprehensible baggage required to start is zero. In other words, Python avoids disrespecting beginners with ugly and tedious compromises, and leaves a clear path to the study of logical and algorithmic thinking, minimally burdened by arbitrary syntax.

AUDIENCES AND OBSTACLES

In discussing the future of Python as a first language, we need to distinguish between several populations of novices:

1) a child working with a parent or other adult

2) a child working alone

3) a child studying a formal course in school

4) a college student studying a formal course

5) an adult seeking to achieve some personal software goal

These audiences have distinct constraints and distinct objectives. It seems clear that, except for very young children, for whom a limited environment such as eToys or Alice may be of great value for more than a few weeks, Python is clearly a viable choice.

Python's competitive position is weakest in the second and third categories, for quite distinct reasons.

In the case of a purely self-motivated child, the child's immediate objective is to do something cool on a web page and email the URL to friends and family. Python is, of course, a very powerful weapon in the hands of the experienced programmer, especially in combination with the vast alphabet soup of frameworks and libraries available. Unlike the core language, though, this power does not scale down to simple applications. Most mass market ISPs do not support Python CGIs, and certainly don't support the likes of Twisted or mod-Python. Also, the libraries and frameworks, though powerful, are conceptually inaccessible to the novice. To the extent that frameworks like Django are easy to use, they probably move far away from Dijkstra' concepts of a pedagogically useful language, and at the extreme Zope/Plone is more of a bureaucracy than a development platform. Compare this with the ease of use and remarkably complete and accessible documentation of PHP, or the zero barrier to entry of Javascript, and we lose the budding web program to pedagogically less valuable languages. Perhaps we needn't worry about the self-motivated young programmer, though. Through their enthusiasm they will learn the limitations of their platform, and eventually move to Python or a similar language. As a youth I programmed in uglier things than PHP and yet lived to tell the tale.

More of an issue is schooling. Adele Goldberg's PyCon keynote was largely a lament about trying to work within the US public school systems. She is giving up on it as a primary goal of her efforts, for a sad litany of reasons. Although her root causes were familiar to me (too much politics, too much fear, no room for experimentation), despite her sad tale she missed a couple of points that are relevant to adding a computing language to the curriculum that would not agitate the good Dr. Dijkstra. First of all, computing (except for advanced placement) is considered a vocational pursuit, not an intellectual one! This madness is endemic; Jeff Elkner's diligent pursual of all that is Pythonic, within a public school system in Virginia, all occurs in the context of a vocational track. Python is considered in competition with VBasic in this context. For college-bound students, Java has become the language of choice as a consequence of the structure of the Advanced Placement examinations. (Everyone seems to agree that this is a pedagogical improvement over C++, which presumably was as baffling to the teachers as the students.) The consequence is that despite the enormous scale of the school system, which would allow for rigorous experimentation and improvement, most schools are stuck teaching Java and VBasic.

In the home or the college, these constraints are not operative. Python First continues to gain momentum in these settings.

ENTER OLPC

Amid all of this mixture of success and frustration, a new five hundred pound gorilla has entered the room. The One Laptop Per Child initiative has promise of reviving the original vision of CP4E:

The project's origins go back more than four decades to the early days of computing, when most machines were still the size of small dinosaurs, and almost no one dreamed they would ever be suitable for children. But pioneering thinkers like Seymour Papert disagreed sharply, and over time led the long march from radical theory to reality proving the immense power of the personal computer as a learning tool for children¹⁹.

Even better, much of the system, and specifically the operating system GUI (called Sugar)²⁰ will be based in Python. Some clever architecture will even allow the child to play with the code! The very large scale and funding of this initiative promise to provide new focus to the CP4E community.

OLPC does an end run around the school bureaucracies of developed countries. In less developed countries, bureaucratic and political obstacles may also be less developed. It provides a Python-friendly platform with massive distribution among children who have not seen code. It promises to enhance the prominence of Python and allow much larger scales of experimentation with pedagogic ideas, all the while being perceived as great fun.

It might not be in time to save the world, but we can hope for that too.

Further Information

Python for Kids

Leo demonstrating PyDoc and EasyGUI

Horst Jens, one of our readers, wrote in to let us know about a great project he is involved with: teaching Python to primary school students in Austria.

The videos themselves are available from the ShowMeDo website²¹, which is a site that accepts user-submitted videos on a variety of software topics. There is an area dedicated to Python, but other languages are also covered.

The ShowMeDo site also allows for users to create wiki spaces for their content. Horst Jens has set up just such an area for his students²², including a description of each students' presentation, the techno-logy they are using and the source code for their work.

Lexi demonstrating a third-party module

Next we take a look at Lexi's presentation. Lexi shows us how to download a third-party module.

Downloading a third-party module is something which most developers will have to tackle and is done differently in each language. Since many important functions are often provided by third-party modules, it is important to be comfortable with their installation and use.

In his presentation, Lexi downloads the EasyGui module. He then performs a few tasks using DrPython to show that EasyGui has been installed successfully and how it may be used.

The next presentation is by Chen, who shows how to define a function using Rurple.

As the wiki puts it, 'Rurple is a very cool, pretty and multi-lingual learning environment for python. It features a little robot that can only be moved forward and made [sic] a 90° left-turn, but he understands some python commands! Using Rurple is a great way to learn/teach/use python'.

Chen demonstrating Rurple

It would be great if Python Papers readers could visit the ShowMeDo website and leave their comments.

The use of Python in education is clearly a significant topic in its own right. In the previous article, Michael Tobis presented an excellent overview of Python in education. As can be seen, Leo, Lexi and Chen have made some fantastic videos. If Python Papers readers know of any other examples of Python being used in education, or would like to let us know their views on this topic, we would love to hear from you!

PyCon 2007 Report

Brett Cannon – amended from his blog post of 2 March²⁴.

I am now back in Vancouver and so I can finally take a breather, sit down, and write about PyCon 2007.

I should begin with the statement that the trip was fantastic! It was probably the best PyCon for me personally as well as the best one in terms of content (or so I heard; more details in a bit). It was also the largest with 594 people in attendance which is amazing considering that is a 43% growth rate compared to last year!

My trip began with an early flight out of YVR (Vancouver) to DFW (Dallas / Fort Worth). When I landed I got my bags, found Michael Hudson, and then met up with Richard Jones (thank you, SMS) to take a taxi from the airport to the hotel. It was a handy thing to plan hotel rides with both Michael and Richard ahead of time so as to not have to lug my tired bum to the airport all by my lonesome.

Illustration 2: Richard Jones (Roundup) attempting to take a photo of himself and the author, not knowing the author is known for ruining photos. (Copyright Richard Jones, 2007)

When we got back, we sat in the bar chatting with various people as they walked past. After people had a drink we went to BJ's for dinner (along the way learning that birds in Texas like to congregate together in trees and let their bowels relax when they get slightly excited when you walk underneath them). I ended up sitting with Richard, Thomas Wouters, Guido van Rossum, Barry Warsaw, and Jeremy Hylton. After eating, Richard left because he was exhausted (his flight is like 26 hours or something from Melbourne). The rest of us chatted for a while and then eventually went back. I don't remember exactly what I did for the rest of that night.

One note about all the meals I ate: I pretty much mention every dinner I ate during the conference as it helps me remember what I did. Most nights it was not that interesting, nor do I expect people to care where I ate on some night, but it's my essay so you just have to live with the unnecessary details.

The intro slide to Ivan Krstic's day one keynote on the One Laptop Per Child (OLPC) project.

After the keynote I did what I did last year: I ignored almost all talks and hacked. I decided I wanted to get my PEP 362 implementation finished before the sprints started (and I did). It was interesting developing some code that is both 2.6 and 3.0 compatible. The biggest trick was remembering to use 'print' the statement or the function.

One of the talks that I did attend on Friday was the python-dev panel that I organized. Steve Holden did a good job as moderator. We had Raymond Hettinger, Neal Norwitz, Andrew Kuchling, Jeremy Hylton and myself on the panel. Thomas Wouters and Barry Warsaw answered some questions from the audience. People seemed to really appreciate the panel (even though the panelists pretty much all wished they could also hear the PyPy taking place next door). Thanks to the panel, it looks like Py3K development will move over to a distributed version control system (most likely Bazaar), in order to make merging back into the trunk easier by having an individual branch for each feature (thus make managing them a simpler action).

I also attended both lightning talks on Friday. I heard people question whether Mike Orr and Jacob Kaplan-Moss kept people to five minutes (which they did) because some of them seemed rather long; that is just a side-effect of boring lightning talks. They were still entertaining overall, though. I gave a lightning talk in the evening about removing automatic unpacking for tuple parameters. The talk, though, backfired as people misread ``def fxn(a, (b, c), d): pass`` as ``fxn(a, *(b, c), d)`` somehow. People were fairly confused throughout most of the lightning talk which basically killed it. Oh well. Lesson learned about trying to quickly ask a large audience about an obscure piece of syntax. In the end, it didn't matter as this feature of Python has been approved for removal since PyCon ended.

Photo by Jacob Kaplan-Moss (Django) of a whiteboard listing various frameworks and the order of preference.

I then hacked on PEP 362 stuff until the Python Software Foundation meeting Friday night. The thing went for three hours! At least we got a free dinner out of it. I managed to get re-elected to the board of directors and "promoted" to executive vice president. I also stayed on as chairman of the infrastructure committee to see through the eventual transition to the new issue tracker.

After the meeting there was plenty of partying on the 12th floor of the hotel in the EWT suite. Raymond Hettinger and Martin Blais both work there along with Christian Tismer doing consulting work. Throughout the conference, that hotel room tended to end up being the place to go at night when you wanted a beer from their bathtub, some wine, or to play some pool.

Saturday's keynote by Adele Goldberg was ignored by me for preference to PEP 362 coding (my mother is a teacher so the whole educational thing is nothing new to me). I did attend the "Scaling Python for High-Load Web Sites" but only partially paid attention. When I attended Jim Hugunin's IronPython talk, though, I listened. Jim's talks are always fun and informative. He has done a great job with recognizing that not everything Microsoft does is great but still giving proper credit when they do things right; in other words he is fair and balanced in terms of his views on Microsoft stuff. Plus Jim always does something cool in his talk, this year being the use of Python to control a little robot that grabbed a ball on the floor using MS's robotics studio (who seeked him out to get Python support!). He also showed a game he coded up using MS's XNA platform (which unfortunately cannot run on the XBox 360 yet as their version of .NET lacks reflection support).

Guido gave his Py3K keynote on Saturday during lunch. People who attended seemed to come out of it much more calm and happy about Py3K and the direction it is taking. Various other people also said they were realizing that the transision from 2.6 to Py3K was being taken seriously and would be as painless as possible. That was a critical event at PyCon as previously many people were panicking about moving their code from the 2.x series to 3.0, but those worries seem to have been calmed.

Saturday also included my security talk. People said it was a great talk and it seemed well-received. No one pointed out a flaw in my design which was good. Overall, people were very supportive and wanted me to get it done and included in the core, which is planned.

That night I went with Thomas, Andy (an officemate of Guido's), Neal, Guido, Jeremy, Barry, and the Python editor from O'Reilly to an Ethiopian restaurant. I learned that Barry is allergic to a bunch of stuff that night.

Sunday's keynote by Robert Lefkowitz was good, but once again I only partially paid attention because of PEP 362 coding. (I basically rewrote the thing from scratch over the span of the conference, if you had not picked up on that fact based on the amount of time I spent on it.)

In terms of talks I went to Sean Reifschnedier's vim talk (Sean is also the man who made the wireless stable this year so kudos to him for that) and the Pybots talk. I discussed some things with Grig Gheroghiu and Titus Brown about testing stuff which was positive.

I saw the lightning talks at the end of the day. The highlight was seeing Richard's Pyglet talk since it had pretty pictures.

At the end of the conference it was announced that PyCon 2008 will be in Chicago, IL. That should be a lot of fun. I went once to Chicago and I loved it. We also did sprint introductions where I represented the core like I seem to do every year. Managed to get some people to join us on the core sprint (probably one of our largest groups in terms of people sticking around for most of the sprint which was great).

For dinner a bunch of us went to a really nice French restaurant that had the chef from the same expensive restaurant we went to last year (The Standard, which was the fancy restaurant we went to last year, had closed a few weeks prior).

Monday was the first day of sprinting. We agreed to the distributed VCS usage for Py3K (Thomas is in charge of making it happen which will probably be in a couple of months). Thomas also backported dict views to 2.6, which is in a branch currently. He also merged his slice removal branch in Py3K (this does not mean that slicing is not possible, it is underlying slicing stuff at the C level).

Initially Pete Shinners (of PyGame fame) did work on adding methods to the bytes type. He eventually moved over to helping Patrick and Eric on a C implementation of PEP 3101 (Advanced String Formatting).

Jerry (whose last name I don't know) converted a bunch of old-style tests to use unittest. Later on his friend Mike helped out.

But first Mike (whose last name I don't know), Daniel (someone else whose last name I don't know), Guido, and I discussed the new I/O design for Py3K. Mike and Daniel then wrote up the PEP which has subsequently been checked in.

Jeremy squashed some crashers that Armin Rigo found (read: a real pain to fix as Armin is notorious for finding really round-about ways of crashing the interpreter).

Neal was supposed to be getting xrange() to become range(), but he got distracted by removing the exceptions module since it serves no real purpose thanks to the module's entire contents being in the built-in namespace.

Guido did stuff with the new I/O library mostly. He also rewrote reload in pure Python.

Barry and I figured out a mechanism to handle the renaming of modules. Using an importer/loader for sys.path and sys.meta_path we came up with a way to map old module names to new ones, basically making the old names virtual.

Monday for me was spent hacking on cleaning up exceptions in Py3K. I made it a TypeError to raise or catch objects that did not inherit from BaseException. I also removed the ability to index/slice on exceptions.

I went out for sushi at a bar on Monday which just seems odd; having plasma screens around you while you eat sushi just doesn't seem quite right to me.

Tuesday was more hacking and the last day Jeremy, Neal and Guido were around. I began my painful quest to remove the 'args' attribute from exceptions and make BaseException take a single argument.

Illustration 3: Day three of sprinting. On the left: Phil Hassey (Galcon), Mike Verdone, Jerry Seutter, and someone whose name escapes me. On the right: the author, Danil Stutzbach, and Pete Shinners (PyGame). Richard Jones (Roundup) is taking the photo. (Copyright Richard Jones 2007)

I ended up catching dinner with Jerry at TGIF's restaurant on Tuesday.

Wednesday night I finally finished my exception work. I have subsequently posted on python-3000 about whether people want to move forward with this as it was extremely painful to pull off (mostly from the change in BaseException's constructor only taking a single argument). It looks like the 'args' attribute on exceptions will stay and the 'message' attribute introduced in 2.5 will be deprecated in 2.6 (might be a record in terms of the lifespan of a feature before it is deprecated).

Because so many people left after Tuesday, we had some of the video game guys move over to our table, including Richard. It was rather cool having the creators of PyGame, pyOpenGL, and Pyglet all in the same room.

We all went out to Thai on Wednesday night.

Thursday I was still mentally recovering from the previous two days of frustration so I just relaxed. I also got everyone at my table hooked on Ohloh. Since a bunch of people there were creators of various projects they had fun looking at the stats on their projects. And writing this paragraph led me to spend way too much time aliasing old SourceForge names to the current svn names, mostly so I could see how I stacked up in terms of commit totals.

I am now home and glad to be back. The trip was great but I was exhausted by the end of it. It was great to meet so many new people (some of whom are not directly mentioned above like Michael Foord, etc.) and old friends (like David Goodger, etc.). As I said, I am already looking forward to the next PyCon as they seem to only become more and more fun!

MPD WebAMP

Chris Seickel

This rather lengthy string of acronyms stands for Music Player Daemon Web-based Asynchronous Music Player client, and is my vision of the perfect music player.

The name pretty much says it all. MPD WebAMP provides a browser based interface to control music playback via MPD. It includes it's own CherryPy web server and provides a single page application with the features and interface one would expect from a standard desktop application. Although it is not unique in it's use of AJAX or it's use of a python based web server, it is unique in that it is a completely asynchronous interface which looks and behaves like an application rather than a web interface.

About Myself

My name is Chris Seickel. I am an amateur programmer who is currently managing a package on the Python Cheese Shop called MPD WebAMP. Professionally, I provide Workstation Support at a small organization and occasionally create Access databases or extend other Microsoft Office products using Visual Basic. Prior to switching full time to Linux, I found Visual Basic easy to use and thought it was the easiest language to learn and the fastest way to get things done. At that point, the only languages I had been exposed to were those in Microsoft's Visual Studio.

Eventually I tried out linux. I was immediately impressed by KDE and the amount of control I had over every aspect of my desktop. Within days I discovered Super Karamba and immediately had to create my own theme. I was amazed by how easily I picked up the scripting language that Super Karamba used. The syntax was straightforward, I typed less, had less typos and could even understand other people's code quickly. The language used by Super Karamba was Python.  Being someone that is rarely content with what's available, I have been exposed to even more languages over the last few years. My initial impression that anything beyond Visual Basic would not be worth the effort to learn has been disproven, and I've learned just how much I was missing out on all of this time.

The Road to 1.0

For some time I have wanted to have my PC connected to my main stereo system, as I now have more music on my computer than anywhere else. I looked at many options, such as plugging in a portable mp3 device, commercial streaming systems, or an open source system running MythTV, Freevo or Geekbox. The problem is, all of the commercially available systems would involve a loss in sound quality and require us to use a small screen interface for browsing our collection and managing our playlist. The linux media packages would allow me better sound quality, but would have the same limitations in the interface as they are designed primarily for TV screens. I also did not want to invest the time needed to set these up properly.

My wife and I are laptop junkies, and we also own a Pepper Pad. The Pepper Pad is a small tablet PC with a touchscreen based on linux which essentially provides a highly modified Firefox browser as the only graphical interface. I had heard of the Music Player Daemon for linux and decided this would fit my needs perfectly and be quick to set up. MPD is a music player that is set up as a network service, allowing you to control the same player from any computer on the network and from any of the many available clients. Since my target platforms all have one thing in common, Firefox, I decided a web interface made the most sense.

There are, of course, many web clients already available. I started experimenting with these, but then my wife asked "why can't I just use Windows Media Player?". The bar was set and the gauntlet thrown down. I had to find, or make, a web based interface to MPD that would compete with Windows Media Player. The more modifications to existing web interfaces I made, the more I learned about web programming. The more I learned, the more I realized what was possible. Since we do not use Internet Explorer at all in my house, even on the Windows PC, this opened up a whole world of technologies that no one else had explored. I quickly realized that I can mimic the layout and feel of my wife's favorite Windows Media Player in a web page using a healthy dose of CSS2, javascript, and server side scripting. The fact that I could also do this without using Flash or Java plugins intrigued me, and I felt that someone had to do it, if for no other reason than to prove that it can be done. My experiences with these plugins on 64 bit and ARM based processors left me a little annoyed at the fact that I am forced to use them to browse the web.

OK, the argument about MythTV and other systems being difficult to setup is now moot, as writing my own interface will certainly require more effort, but at this point it doesn't matter. I was actually looking for a chance to learn about web programming and I was immediately excited about this particular project. I am a geek, I can't deny it.

Unfortunately, no one else at this time had created an interface anywhere near the level of a desktop application, so I started from scratch. After a month with PHP and Dojo, I had only the most basic functions complete, having spent half my time hunting typos in PHP and digging through source code in Dojo. I started to yearn for a better server side scripting language and a faster, better documented Javascript library. That's when I found CherryPy and MochiKit, which quickly led to TurboGears, which integrates these and other Python pieces into one web development package. Within a month of switching to Turbo