The Python Papers Anthology

PyCon Asia-Pacific 2010 - Call for Papers

Frontmatter (Volume 4 Issue 3)

Second Call for Papers for PyCon Asia-Pacific 2010

The OLPC XO: Python bringing education to the world's poorest children (and how you can help!)

Title, Sponsors, License Disclaimer, Preface, Organising Committee and Table of Published Paper

New Zealand Python User Group Incorporated

Kiwi PyCon 2009 (New Zealand) - Title and Front Matters

New Zealand Python User Group

Kiwi PyCon 2009 – Call for Talks, Papers and Tutorials
Kiwi PyCon 2009 is an independent, community-run, community-controlled and 
not-for-profit conference dedicated to the Python programming language, 
Python applications, toolkits and frameworks. It also features social events and 
a chance to meet fellow Python users. It is organised by the New Zealand 
Python User Group http://nzpug.org.
Kiwi PyCon 2009 will be taking place at the Canterbury Innovation Incubator in 
Christchurch on the week end from the 7th through 8th November 2009. We are 
looking for Talks, Tutorials, Lightning Talks, Demos, Open Spaces and lots of 
hall way interaction. To submit a talk, please visit our submissions page 
http://nz.pycon.org/submit-talk.
We're looking for proposals on all aspects of Python - programming from novice 
to advanced levels; applications and frameworks, or how you have been 
involved in introducing Python into your organisation. 
We especially welcome first-time speakers; we are a community conference and we are eager to hear about your 
experience. If you have friends or colleagues who have something valuable to contribute, twist their arms to tell us 
about it! Please also forward this Call for Papers to anyone that you feel may be interested.
Instructions for Presenters
We will accept a broad range of presentations, from 
reports on academic and commercial projects to tutorials 
and case studies. As long as the presentation is 
interesting and potentially useful to the Python 
community, it will be considered for inclusion in the 
programme. It's easy ... Can you show the conference-
goers something new and useful? Can you show 
attendees how to: Use a module? Explore a Python 
language feature? Package an application? 
All presentations (except lightning talks) must be 
accompanied by presentation materials. A detailed 
paper complementing your talk matter would be 
preferred - your slides merely illustrate your verbal 
presentation. 
We will accept the following types of presentation: 
• Lightning Talks/Quick Fire Demo (5 minutes) - You 
don't need to submit a proposal for a Lightning Talk. 
These will be organised from sign-up sheets at the 
conference. Instructions will be given on the first day.
(Lightning Talks are brief talks that focus on a single 
example, idea, project or technique. Lightning Talks 
are not expected to cover all aspects of the subject.  
They're an excellent forum for first-time speakers.) 
• Standard (30 minutes) - This is the preferred format. 
20 minutes for talking and 5 minutes for questions 
(with 5 minutes spare for set-up and take-down). This 
is enough time to cover a few issues well and allows 
us to provide a good selection of talks throughout the 
day. 
• Extended (45 or 60 minutes) - Extended talks are 
ideal for experienced speakers who want to cover a 
large topic. 45 minutes for talking and 10 minutes for 
questions (with 5 minutes spare for set-up and take-
down). 
If you choose the longer time slot please include a 
request in your proposal.
Submission
Proposals should be succinct summaries containing the 
following information: 
• Author name(s), and a bit of bio info 
(include a bit about your qualifications regarding 
your presentation topic) 
• Contact Information 
• Preferred timeslot (standard or extended) 
• Title of proposed presentation 
• Summary of proposed presentation 
(around 30 words) 
• Presentation outline (around 200 words) 
• Intended audience (some keywords and 
non-programmers, beginning programmers, 
advanced users, CPython developers, etc.) 
Don't panic! We don't require you to have written the 
technology that you want to talk about. If you use 
something in your day to day working life and you think 
that other people might benefit from using it, then feel 
free to propose a talk on it. 
Submit your proposal: http://nz.pycon.org/submit-talk
If your proposal is accepted, you have the option of 
including a companion paper along with your 
presentation. The paper will get published in The Python 
Paper Monograph series http://pythonpapers.org. We 
suggest, but do not require, that authors place their 
papers under the Creative Commons license.
Kiwi PyCon 2009 · Christchurch · 7–9 November 2009 · Brought to you by NZPUG: http://nzpug.org
Important Dates
• Submission deadline of proposals:
SUN, 2 August 2009
(But the sooner the better!)
• Acceptance notification:
SUN, 20 September 2009
• Deadline for handouts/camera ready paper
SUN, 11 October 2009
• The Event:
7–8 November 2009 
Kiwi PyCon 2009 – Call for Talks, Papers and Tutorials
Proposals Acceptance
All proposals will be reviewed. Authors will be notified of 
the acceptance of their proposal by the proposal 
acceptance date. Obviously we'd love to accept as many 
proposals as we can, but we only have a certain number 
of sessions to fill. If you require faster confirmation of 
acceptance (for example, because you are travelling 
from overseas and require extra time to make 
arrangements) please communicate this to the 
committee when submitting your proposal. 
(Final) Paper/Handout Submission
All presenters are required to submit presentation 
materials by the specified date. This submission is to be 
your full paper, not a draft. It should contain all of the 
usual aspects of a paper such as an abstract, 
introduction, body and conclusion. Please ensure that 
this submission has had its grammar and spelling 
corrected and that code snippets work. Your paper 
allows attendees who attended your talk a chance to 
refresh their memories about your presentation, and 
gives attendees who missed your talk a chance to learn 
from you anyway. Make sure your paper includes - at 
the very least - a brief introduction to your subject 
material and a list of further resources. 
We would prefer that papers for standard length talks 
(30 minutes) be no more than 5 A4 pages of 11-point 
type with reasonable margins and papers for long talks 
(45 or 60 minutes) be no more than 10 pages. 
Appropriate file formats include any file that can be read 
with Open Office (which includes plain text and HTML 
with minimal mark-up) or a PDF viewer. Slides (even 
those accompanied by speaker notes) will not be printed 
in the proceedings. 
Papers from other PyCons provide a good range of 
sample paper layouts. 
Paper Review
All papers for the proceedings will be reviewed. The 
purpose of review is to ensure that papers are of a high 
quality and to aid our talk scheduling. The purpose is not 
to identify spelling or grammatical errors or to test code 
snippets, although errors may be corrected during the 
review if found. Obviously, we'd strongly recommend 
you ask a friend or colleague to give your paper a read 
through before you submit it. 
Once your paper has been reviewed, the review results 
will be provided to you so that you can make the 
requested improvements for the published version. In 
case of acceptance the version to submit then is the 
final copy of your paper as it will appear in the 
conference proceedings (in The Python Paper 
Monograph Series http://pythonpapers.org). This is a 
separate process, and you will receive further 
information upon submitting your paper. 
Speaker Benefits
Of course the fame that comes with it! Beyond that, all 
speakers (except for Lightning Talks) will have a 
reduced conference registration fee of $10. 
Note that it's important that you get your papers in by the 
due dates - we reserve the right to withdraw the reduced 
registration if you don't get it in on time. If you're having 
problems meeting the deadlines, please let us know as 
soon as possible so that we can work with you to figure 
it out.
Topics
Suitable topics for Kiwi PyCon presentations include, but 
are not limited to:Core Python
• Other implementations: 
Jython, IronPython, PyPy, and Stackless
• Python libraries and extensions
• Python 3k
• Databases
• Documentation
• GUI Programming
• Game Programming
• Network Programming
• Open Source Python projects
• Packaging Issues
• Programming Tools
• Project Best Practices
• Embedding and Extending
• Science and Math
• Web-based Systems
Contact details
Meanwhile, if you have questions or want to suggest another conference event, please contact the organisers: 
kiwipycon@nzpug.org
Kiwi PyCon 2009 · Christchurch · 7–9 November 2009 · Brought to you by NZPUG: http://nzpug.org


Kiwi PyCon 2009  Call for Talks, Papers and Tutorials

EuroPython in Vilnius and Beyond
Paul Boddie
EuroPython Volunteer
paul@boddie.org.uk
Abstract
Organising and attending a volunteer­run Python conference can be a lot of work. 
This article describes a few of the activities around the EuroPython conferences in 
2007 and 2008, briefly reviews some of the author's favourite talks, and looks 
forward to EuroPython 2009 and beyond.
1. Introduction 
As many Python users may be aware, the Python community holds a number of 
different   conferences   across   the   globe   for   anyone   with   an   interest   in   Python 
programming,  with  more   specialised   Python­related   conferences   –   on   scientific 
computing and Web technologies, amongst other things – also offering learning and 
socialising  opportunities   for   their  own  corners  of   the  wider  Python  community. 
EuroPython   is   the   volunteer­run   conference   for   the   Python   community   and 
associated communities in Europe, although attendees from anywhere in the world 
are welcome; for the past two years the EuroPython conference has been held in 
Vilnius, Lithuania.
2. EuroPython in Vilnius
Vilnius   is   the   furthest   to   the  east   that   the  EuroPython  conference  has   travelled, 
having started in Charleroi,  Belgium in 2002 and having moved via Gothenburg, 
Sweden and Geneva, Switzerland in previous years. As a result, the conference gave 
visitors an extra reason to travel to Lithuania and to experience yet another part of 
Europe, and this was certainly a motivating factor for those of us who have lived, 
studied, worked and travelled mostly in western Europe. In addition, the proximity 
of Lithuania to vibrant Eastern European Python communities in Poland, Ukraine, 
Russia and, of course, the community of users in Lithuania itself, was intended to 
­ 1 ­
encourage these more local groups to attend and to share their experiences with the 
rest of the gathered audience. As a member of the European Union, Lithuania offers 
relatively problem­free travel arrangements for most Europeans, with arrangements 
for other visitors also becoming simpler in 2008, at least in theory, when Lithuania 
became a member of the Schengen Area: a pan­European area where passport and 
visa arrangements are somewhat unified and where freedom of movement is, also in 
theory, increased. As a consequence, EuroPython attracted a respectable number of 
attendees from as far away as the United States as well as a healthy number from 
neighbouring Poland, and with many people travelling from places somewhere in­
between.
Figure 2.1. Picturesque Vilnius!
3. EuroPython's Organisational Conventions
It is traditional, with only the CERN­based EuroPython 2006 as an exception, that 
the   conference   be   held   for   two   consecutive   years   in   each   location,   with   one 
justification for this being the potential for fine­tuning and improving the conference 
experience  after   the   first  year.  But   the  organisation  of  a  conference   is  not  only 
concerned with that which happens at  the venue, even though a huge amount of 
­ 2 ­
preparation   is  performed by  the  local  volunteers.  An  infrastructure  must   first  be 
constructed   to   publicise   the   conference,   inform   potential   attendees   of   planned 
events, solicit and accept proposals for talks and other activities, plan the conference 
timetable, and much more, all happening without any particular connection to the 
exact location of the conference, although the practical details of travelling to and 
staying at the venue are best written up by members of the local team. Thus, the 
wider organising team for a conference like EuroPython consists of a mixture of 
local and global volunteers, with some of the latter group perhaps not even attending 
the conference at all!
After EuroPython 2006, the composition of the organising team changed somewhat: 
CERN, whose attentions were now to be focused on the Large Hadron Collider, 
would   obviously   play   a   diminished   role   in   EuroPython   2007,   with   the   local 
organisers  stepping  aside  and handing control   to   the  new local   team in Vilnius. 
However, it was decided that CERN's conference infrastructure could still be used 
for EuroPython 2007, permitting a large amount of the pre­conference preparations 
to be done without the distraction of choosing or developing such infrastructure all 
over again. But as with any major change in the organisation of an event, it was with 
some trepidation that the preparations for EuroPython 2007 began: what surprises 
might arise and push the organisers to their limits?
4. A Selection of Talks from EuroPython 2007
To cut a long story very short,  so as not to dwell  on the details  of organising a 
conference, EuroPython 2007 proved to be a success with the organisers working 
hard to make the conference a rewarding experience. A number of informative and 
entertaining talks were proposed,  approved and delivered,  and although everyone 
presumably has their own favourites, here are the author's choices:
● Extending   Python   with   EasyExtend  ­   with   controversy   over   every 
language change in CPython, the presenter described his system for making 
one's own variants of Python with customised syntax. Although one might 
suggest   that   a   proliferation   of   Python   variants   might   somehow   "dilute 
Python" in some way, benevolent  dictator of Python, Guido van Rossum, 
seemed enthusiastic, perhaps because EasyExtend offers a sandbox for the 
more   enthusiastic   language   experimenters  without   distracting   the  Python 
core developers with arguments about syntax on a frequent basis.
­ 3 ­
● Tux Droid, a python­fueled robot ­ hardware does not really appear often 
enough   at  EuroPython,   so   it  was   refreshing   to   see   the  Tux  Droid   open 
hardware project demonstrated with much humour at   the conference.  The 
presenter   managed   to   entertain   the   audience   with   a   well­timed 
"conversation" with his robot companion, and having presented the technical 
details (and the Python angle), was selling units to interested parties after his 
talk.
● Keynote  by Simon Willison  ­   although well­known for  his   involvement 
with the Django project, our keynote speaker sought to inform his audience 
about   the   merits   of   the   OpenID   authentication   technology,   as   well   as 
providing memorable visuals: "And Microsoft don't get to own everyone's 
credentials."
● Measuring Python Performance ­ scheduled only against Open Space and 
in a small room, the presenter played to a full house with an informative talk 
about what could be regarded as a dry topic. Plenty of practical advice was 
dispensed,   leading   your   correspondent   to   investigate   various   tools   upon 
returning to work and having to investigate his own performance problems.
So, with EuroPython 2007 under their belt, the organisers now had a few months 
rest before turning their attentions to the planning of EuroPython 2008.
5. The Pitfalls of Organising a Programming Conference
It can be said with some justification that much time is spent, when organising a 
programming conference, on the tools to be used to run the conference, as opposed 
to the matter of actually organising the conference itself. Every year, the matter of 
the conference Web site is raised, with suggestions made on the development of a 
better site with more advanced features and, one might say, more of a "Web 2.0" 
feel   to   it.  For a  number of  years,   the EuroPython Web site  had been running a 
solution which did not appear to be very popular with those responsible for adding 
content, although the author finds it necessary to point out, as one of the editors of 
the site, that although the solution may have been somewhat rigid, it was capable 
and suitable for the job.
Nevertheless, the matter of a new site arose once again with a moderate amount of 
enthusiasm   but   relatively   little   contribution   towards   that   goal.   Now,   other 
conferences (such as PyCon UK) had experienced good things by deploying a Wiki 
­ 4 ­
solution   for   their   attendees   to   use   and   to   edit,   thus   providing   the   collaborative 
features that many regarded as absent from the existing EuroPython site, and so a 
solution based on the popular Python­based Wiki MoinMoin was developed, not just 
as a medium for attendees   to organise  their  own activities,  but also as  the main 
vehicle for information about the conference. Although it may seem counterintuitive 
to use a Wiki as a means to deliver information that may not necessarily be editable 
by anyone, MoinMoin provides a sufficient level of control to permit a hybrid site 
where some parts are almost freely editable while other things, such as the page 
telling attendees how to pay for their registration, remain strictly read­only.
Figure 5.1. The EuroPython 2008 Web site.
6. A Selection of Talks from EuroPython 2008
Again, a large amount of work went into organising EuroPython 2008, at the global 
and local levels, with any problems encountered in 2007 taken into account in an 
attempt   to   avoid   their   repetition   in   2008.   The   end   result  was,   once   again,   an 
enjoyable experience at the same venue with the opportunity to see the changes in 
Vilnius   itself   from one  year   to   the  next.  The   talks  were   also   satisfying,   and   a 
selection of the author's favourites appear below.
­ 5 ­
● cocos2d, a framework for building 2d games ­ with the presenters almost 
becoming   EuroPython   regulars,   despite   travelling   all   the   way   from 
Argentina,   they   took   this   opportunity   to   demonstrate,   as   a   duo,   the 
capabilities of their game programming framework, showing off impressive 
special effects and an impressively simple programming interface.
● Duplicate Code Detection using Clone Digger  ­ the presenter, coming all 
the way from Moscow, delivered a talk on an intriguing topic: how to detect 
duplicate   code   fragments   in   programs.  The   solution  proposed   is,   as   one 
might   expect   after   a   moment's   consideration,   relatively   demanding   on 
computing resources, but appeared to be interesting to many people working 
in related fields such as parsing, program compilation and refactoring.
● Dynamic Compilation in Python and Jython ­ although not as advanced as 
its title suggests, this talk did much to inform the audience about the progress 
of Jython and the renewed focus on that particular  implementation of the 
Python  language system.  Indeed,  EuroPython 2008 received  a   reasonable 
amount   of   focus   from   Sun   Microsystems,   the   originators   of   the   Java 
programming  language and environment,  with a  number  of  employees   in 
attendance as part of a reinvigoration of their Python­related efforts.
● Using Python in the Amazon Cloud to Analyze your own DNA ­ part of 
the EuroPython experience involves seeing the intersection of different fields 
of endeavour,  all enabled by Python, and this talk combined the fields of 
bioinformatics  and cloud computing   to   illustrate   the benefits  of   the  latter 
with respect to the demands of the former, all within a practical context. 
Certainly,   the   combination   or   collision   of   disciplines   was   well   represented   at 
EuroPython 2008: a keynote speech by Hans Rosling of the Gapminder Foundation 
focused on the need for useful visualisation in order to inform decision­making on 
public policy and global health issues. Although some might wonder why a talk on a 
non­programming topic might be given at a conference like EuroPython, it is always 
worth remembering that software development usually has to perform a job with an 
ultimately "real world" purpose or effect. Such non­programming topics should help 
to   inform  Python   programmers   about   the   deficiencies   in   the   software   used   by 
practitioners of other disciplines and inspire us to do better at delivering useful tools 
to such people.
­ 6 ­
Figure 6.1. Hans Rosling improvises with the microphone stand.
7. Looking Forward to EuroPython 2009
So, Vilnius and EuroPythons 2007 and 2008 have provided their attendees with a lot 
of material both of practical value as well as material for further contemplation on a 
more holistic level. Now that 2009 has begun, one must now wonder what the plans 
are  for EuroPython 2009. Well,   for more  than a year,  a  team involved with the 
PyCon  UK   conference   has   been   preparing   to   take   control   of   the   EuroPython 
activities and to bring the conference to Birmingham, England for 2009 and 2010. 
Preparations are well underway, and announcements have already been made with 
regard to talks, registration and other activities around the conference. By the time 
you read this, the conference may almost be upon us, so if you like what you have 
read and have an interest in learning new things about Python and its community, or 
if   you   are   a   European   Python   user   with   aspirations   of   seeing   a   EuroPython 
conference in your own city in the future, do not delay: register for the conference 
while  any opportunity   to do so remains! The EuroPython organisers  and regular 
participants look forward to seeing you in Birmingham from Tuesday 30th June to 
Thursday 2nd July. Perhaps you will even stay for the tutorials before and the sprints 
afterwards? In any case, see you there!
­ 7 ­
8. Resources
The EuroPython Web site, http://www.europython.eu/
Talk Abstracts (from EuroPython 2008), 
http://www.europython2008.eu/Talks_and_Themes/Abstracts 
Timetable from EuroPython 2007, http://indico.cern.ch/conferenceTimeTable.py?
confId=13919&detailLevel=contribution&viewMode=room
The MoinMoin Wiki software, http://moinmo.in/
­ 8 ­


EuroPython in Vilnius and Beyond

There are many clever ways of connecting Python and C code together, but pyserf is not one of those. It is just a short script that parses a module outline and produces an idiomatic template for a C extension providing the same signatures, so all you need to do is write the bits that actually do stuff

Pyserf. A shortcut for writing C extensions in C  
Douglas Bagnall
Pictorial Research Group
douglas@paradise.net.nz
Abstract
There are many clever ways of connecting Python and C code together, but pyserf is 
not one of those. It is just a short script that parses a module outline and produces an 
idiomatic template for a C extension providing the same signatures, so all you need 
to do is write the bits that actually do stuff.
1. Introduction 
As stated in the abstract, there are a whole lot of ways to connect Python to C.  I 
don't know much about them, so I wrote my own.  Twice actually.  More on that 
later.
1.1 Approaches to binding C to Python
One way to classify extension techniques is which language interface they focus 
upon.  You can call  then  C-centric (or  C++-centric, etc.,  but it  does not read so 
well), or Python-centric.  A C-centric system is more likely to provide you with an 
interface like the I/O parts of the standard library’s os module – lots of functions and 
mysterious constants inherited verbatim from libc – while a Python-centric system 
might produce something explicable on the outside – like the file built-in type – but 
full  of  bizarre  hacks`  internally.   Most  systems  attempt  to  break  this  down and 
become  glue-centric –  becoming  very  useful  but  somewhat  stuck  in  their  own 
assumptions.
1.1.1 Examples of C-centric and Python-centric techniques
SWIG is the archetype of a C-centric interface. Ctypes is Python-centric.  Boost and 
Pyrex are each in their ways more glue-centric.
2  Where pyserf fits in.
Pyserf  is  a  tiny project  that  creates  a  C source  template  from a python  file,  by 
traversing  the  Python  syntax  tree  and  picking  out  the  signatures  of  classes  and 
functions.  The code it produces is similar to that which would be produced by a 
human following the official extension writing tutorial. It is thus Python-centric, in 
that the interface is entirely defined by a Python outline, and also C-centric, in that it 
writes clean unsurprising C.  To achieve this it completely abandons the pretence of 
gluing or translating anything.  The C module will compile (and pyserf will create a 
Makefile and a setup.py to help), and it will import, and every callable will work 
exactly as expected, except that it won’t actually  do anything. Pyserf is for people 
who are comfortable in Python and in C, but not in the boilerplate that is needed to 
- 1 -
bind them.  It does no magic, just boring work.  Hence its name, placing it on the 
lowest rungs of Pyrex’s kingdom.
2.1 Example
If you had a file “frog.py” containing the following code, which you will find does 
nothing:
"""Frog and Pelican recognition module"""
class Spotter:
    """This class can tell you whether an image contains a frog or a
    pelican.  In the case of frogs, it can tell you how many there
    are."""
    
    def __init__(self, buffer):
        """buffer should be a PIL image buffer"""
    def contains_pelican(self):
        "does the picture depict a pelican? (boolean)"
        return answer
    def count_frogs(self, tadpoles):
        """How many frogs in the picture? If tadpoles is true, 
        they are counted too."""
        print "code here is ignored, except returns and __doc__."
        return int_frogcount
def defrog(buffer, tadpoles):
    """Remove any frogs and optionally tadpoles 
    from a given image"""
running pyserf.py frog.py will produce a file “frog.c” containing the following 
(excuse Openoffice’s formatting): 
#include <python2.6/Python.h>
#include "python2.6/structmember.h"
/**********************************************************************/
/* headers.                                                           */
/**********************************************************************/
typedef struct {
    PyObject_HEAD
    /* XXX define frog.Spotter objects here. */
} frog_Spotter_object;
static PyObject *frog_defrog (PyObject*, PyObject*);
static void Spotter___dealloc__ (PyObject*, PyObject*);
static PyObject *Spotter___init__ (PyObject*, PyObject*);
static PyObject *Spotter_contains_pelican (PyObject*, PyObject*);
static PyObject *Spotter_count_frogs (PyObject*, PyObject*);
/**********************************************************************/
/* functions and methods                                              */
/**********************************************************************/
/* frog_defrog (binds to frog.defrog) */
- 2 -
/* Remove any frogs and optionally tadpoles from a given image 
*/
static PyObject *
frog_defrog (PyObject *self, PyObject *args)
{
    PyObject *buffer;
    PyObject *tadpoles;
    if (!PyArg_ParseTuple(args, "OO", &buffer, &tadpoles))
        return NULL;
    /* XXX your code here */
    return Py_BuildValue("");
}
static void Spotter___dealloc__ (PyObject *self, PyObject *args)
{
    self->ob_type->tp_free((PyObject*)self);
}
/* Spotter___init__ (binds to Spotter.__init__) */
/* buffer should be a PIL image buffer 
*/
static PyObject *
Spotter___init__ (PyObject *self, PyObject *args)
{
    PyObject *buffer;
    if (!PyArg_ParseTuple(args, "O", &buffer))
        return NULL;
    /* XXX your code here */
    return Py_BuildValue("");
}
/* Spotter_contains_pelican (binds to Spotter.contains_pelican) */
/* does the picture depict a pelican? (boolean) 
*/
static PyObject *
Spotter_contains_pelican (PyObject *self, PyObject *args)
{
    PyObject *answer;
    /*no arguments to parse (using METH_NOARGS) */
    /* XXX your code here */
    return Py_BuildValue("O", answer);
}
/* Spotter_count_frogs (binds to Spotter.count_frogs) */
/* How many frogs in the picture? If tadpoles is true, they are 
*/
/* counted too. 
*/
static PyObject *
Spotter_count_frogs (PyObject *self, PyObject *args)
{
    int frogcount;
    PyObject *tadpoles;
    if (!PyArg_ParseTuple(args, "O", &tadpoles))
        return NULL;
- 3 -
    /***  ignoring these lines of python  ***/
    /*         print "code here is ignored, except returns and __doc__." */
    /***  finished ignoring  ***/
    /* XXX your code here */
    return Py_BuildValue("i", frogcount);
}
/**********************************************************************/
/* method binding structs                                             */
/**********************************************************************/
/* bindings for frog */
static PyMethodDef top_level_functions[] = {
    {"defrog", (PyCFunction)frog_defrog, METH_VARARGS,
    "Remove any frogs and optionally tadpoles from a given image"},
    {NULL}
};
/* bindings for Spotter */
static PyMethodDef Spotter_methods[] = {
    {"contains_pelican", (PyCFunction)Spotter_contains_pelican, 
METH_NOARGS,
    "does the picture depict a pelican? (boolean)"},
    {"count_frogs", (PyCFunction)Spotter_count_frogs, METH_VARARGS,
    "How many frogs in the picture? If tadpoles is true, they are"\
    "counted too."},
    {NULL}
};
/**********************************************************************/
/* type definition structs                                            */
/**********************************************************************/
static PyTypeObject frog_Spotter_type = {
    PyObject_HEAD_INIT(NULL)
    0,                                             /*          ob_size */
    "frog.Spotter",                                /*          tp_name */
    sizeof(frog_Spotter_object),                   /*     tp_basicsize */
    0,                                             /*      tp_itemsize */
    (destructor)Spotter___dealloc__,               /*       tp_dealloc */
    0,                                             /*         tp_print */
    0,                                             /*       tp_getattr */
    0,                                             /*       tp_setattr */
    0,                                             /*       tp_compare */
    0,                                             /*          tp_repr */
    0,                                             /*     tp_as_number */
    0,                                             /*   tp_as_sequence */
    0,                                             /*    tp_as_mapping */
    0,                                             /*          tp_hash */
    0,                                             /*          tp_call */
    0,                                             /*           tp_str */
    0,                                             /*      tp_getattro */
    0,                                             /*      tp_setattro */
    0,                                             /*     tp_as_buffer */
    (long)Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, /*         tp_flags */
    "This class can tell you whether an image contains a frog or a"\
    "pelican.  In the case of frogs, it can tell you how many there"\
    "are.", /*           tp_doc */
    0,                                             /*      tp_traverse */
    0,                                             /*         tp_clear */
    0,                                             /*   tp_richcompare */
    0,                                             /*tp_weaklistoffset */
    0,                                             /*          tp_iter */
    0,                                             /*      tp_iternext */
- 4 -
    (struct PyMethodDef *)Spotter_methods,         /*       tp_methods */
    0,                                             /*       tp_members */
    0,                                             /*        tp_getset */
    0,                                             /*          tp_base */
    0,                                             /*          tp_dict */
    0,                                             /*     tp_descr_get */
    0,                                             /*     tp_descr_set */
    0,                                             /*    tp_dictoffset */
    (initproc)Spotter___init__,                    /*          tp_init */
    0,                                             /*         tp_alloc */
    (newfunc)PyType_GenericNew,                    /*           tp_new */
    0,                                             /*          tp_free */
};
/**********************************************************************/
/* initialisation.                                                    */
/**********************************************************************/
#ifndef PyMODINIT_FUNC
#define PyMODINIT_FUNC void
#endif
PyMODINIT_FUNC
initfrog(void)
{
    PyObject* m;
    if (PyType_Ready(&frog_Spotter_type) < 0)
        return;
    m = Py_InitModule3("frog", top_level_functions,
        "Frog and Pelican recognition module");
    if (m == NULL)
        return;
    Py_INCREF(&frog_Spotter_type);
    PyModule_AddObject(m, "Spotter", (PyObject *)&frog_Spotter_type);
}
Then, as a programmer wanting to write a Python extension in C, you go to all the 
places marked “XXX your code here” and insert your code, which deals only with C 
values and only has to produce C values, so long as you stick to the API that you 
defined for yourself in the template.
2.2 Problems
Areas where pyserf does not excel:
• Pyserf can’t patch an existing C file.
• The Python AST interface changes regularly.
• It doesn’t handle every case.
• It doesn’t actually do anything.
2.3 Advantages
It is only 500 lines of code.  Even with a huge bugs to lines ratio, it mostly works.
- 5 -


Pyserf. A shortcut for writing C extensions in C

An introduction to Stackless Python, showing what it is useful for and how to use it

Stackless Python 101 - Handout
Richard Tew
richard.m.tew@gmail.com
Abstract
An introduction to Stackless Python, showing what it is useful for and how to use it. 
1. Introduction 
Stackless Python is an extended version of the Python programming language.  This 
presentation is intended to provide a general overview of it.  From what makes it 
different and better than similar solutions, to a high level introduction to the small 
amount you need to know to use it.
2. Code Snippets
Creating a tasklet.
stackless.tasklet(callable)(*args, **kwargs)
Running the scheduler cooperatively.
stackless.run()
Running the scheduler preemptively.
stackless.run(numberOfInstructions)
Yielding the current tasklet to allow the others to run.
stackless.schedule()
Creating a channel.
channel = stackless.channel()
Receiving a value through a channel on the current tasklet.
value = channel.receive()
Sending a current value through a channel on the current tasklet.
channel.send(value)
Checking whether there are sending tasklets blocked on a channel.
channelHasBlockedSenders = channel.balance > 0
Checking whether there are receiving tasklets blocked on a channel.
channelHasBlockedReceivers = channel.balance < 0
- 1 -
3. Links
Stackless Python web site.
http://www.stackless.com
Stackless Python examples web site.
http://code.google.com/p/stacklessexamples/
- 2 -


Stackless Python 101 - Handout

Learn how to use your knowledge of Python to control objects in the Real World (TM) with the Arduino open-source electronics prototyping platform and physical computing

Charming the real world :
Python meets the Arduino and physical computing  
Philip J. Lindsay
rancidbacon.com
follower@rancidbacon.com
Abstract
Learn how to use your knowledge of Python to control objects in the Real World™ 
with the Arduino open-source electronics prototyping platform and physical 
computing.
1. Introduction 
While  many  people  are  interested  in  what  is  now  described  as  “physical 
computing”—creating  devices  that  interact  directly  with  users  and  the  physical 
world—the thought of using low level languages to develop such devices can be off-
putting.  From  this  presentation  you  will  learn  how  you  can  create  interactive 
physical  computing  projects  but  still  use  your  high  level  language  of  choice 
(assuming it's Python :) ).
We'll cover how to get started with both the Arduino hardware and software, how to 
use Python with the platform and the options available to make your life easier.
Example physical computing projects will be described and the possible future of 
high-level language physical computing devices will be considered. Learn how to 
use the Arduino as a sensor input platform and how to control lights and actuators.
Possible  uses  include  physical  sensing  and  visible  process  feedback  for  build 
processes and network monitoring. Your imagination is the limit! Specific Python 
libraries referenced include PySerial, python-firmata and pyusb.
1.1. Arduino
The  Arduino  (http://arduino.cc/)  is  described  as  “an  open-source  electronics 
prototyping  platform based  on  flexible,  easy-to-use  hardware  and software.  It  is 
intended  for  artists,  designers,  hobbyists,  and  anyone  interested  in  creating 
interactive objects or environments.”
- 1 -
If you are unfamiliar with the types of projects possible have a look at the archives 
of a blog like Make magazine (http://blog.makezine.com/archive/arduino/).
While the platform was originally designed to appeal to a primarily non-technical 
audience  in  the  form of  artists  and  designers  it  has  also  gained  the attention  of 
individuals with technical knowledge such as software developers. For myself the 
appeal of the system is that it makes hardware and electronics development much 
more accessible. What used to be a 100% hardware or electronics problem became 
90% a software problem by using a micro-controller and the Arduino “language”. 
The 10% of the problem remaining in hardware was more easily solved by learning 
the small  amount  of electronics  knowledge required on an as needed basis.  The 
Arduino community  also  provided  an environment  geared  towards  helping  new-
comers to electronics gain the knowledge they needed.
2. Python/Arduino communication options
In order to support communication with the Arduino board a method of interfacing 
is  required.  Standard  Arduino  boards  provide  a  RS232-style  serial  connection—
older boards provided this over a physical RS232 connection but with such a port no 
longer  common  on  modern  computers  recent  boards  include  USB  to  serial 
functionality.
This section considers the options available for the Python side of the interface and 
what needs to be installed on the Arduino for successful communication. Programs 
written for the Arduino are known as "sketches" because apparently that sounds less 
intimidating.
2.1 Raw serial
On some operating systems it  is possible to interact  with the Arduino simply by 
opening  the  serial  device  as  a  file  by  using  open() or  os.open() but  this 
approach is not cross-platform.
There is a script available which demonstrates how standard Python libraries can be 
used on some systems to communicate with an Arduino 
(http://lemonodor.com/archives/2008/02/arduino_serial.html).
A customised script would need to be installed on the Arduino.
Due to the issues related to using raw serial access and the options available we will 
not consider this option further.
2.2 pyserial
The standard cross-platform provider of serial support is the library pyserial 
(http://pypi.python.org/pypi/pyserial). It provides support for BSD, Linux, 
Windows, Mac OS X and Jython.
- 2 -
It can be installed via easy_install or the source downloaded and installed with 
the usual setup.py approach.
Once a suitable sketch (e.g. the standard ASCIITable example sketch) is uploaded 
to the Arduino the following code can be used to communicate with the device:
>>> import serial
>>> s = serial.Serial("/dev/tty.usbserial-XXXXXX")
>>> s.readline()
'\x00ASCII Table ~ Character Map\r\n'
>>> s.close()
 
In order to control the input or output pins and other functionality a customised 
sketch to act in response to data received over the serial port would be required.
2.3 python-firmata
Firmata  (http://firmata.org/)  is  "a  generic  protocol  for  communicating  with 
microcontrollers from software on a host computer". There is an associated Arduino 
library  (http://arduino.cc/en/Reference/Firmata)  and  Python  library  support 
(http://github.com/lupeke/python-firmata/). 
The combination of Python and Firmata enables you to install a standard sketch (e.g. 
StandardFirmata) on your Arduino and then control it completely from Python 
without needing to write any custom Arduino code. The protocol and the sketch are 
extensible if you do wish to create additional functionality.
Example Python usage:
>>> from firmata import *
>>> a = Arduino('/dev/tty.usbserial-XXXXXXXXXX', baudrate=57600)
>>> a.pin_mode(13, firmata.OUTPUT)
>>> a.digital_write(13, firmata.HIGH) # LED on pin 13 on
>>> a.digital_write(13, firmata.LOW) # LED on pin 13 off
>>> a.serial.close()
Further  details  about  the installation  and use of  Arduino,  Python and Firmata  is 
available (http://code.rancidbacon.com/LearningAboutArduinoandPython).
This approach is enables the majority of your code to be written in Python.
2.4 Network
With  the  addition  of  the  official  Arduino  Ethernet  shield  or  another  wired  or 
wireless Ethernet shield it is possible to communicate with the Arduino via standard 
network protocols such as telnet and HTTP.
These require a customised sketch on the Arduino.
As  part  of  the  Flashduino  (http://code.rancidbacon.com/Flashduino)  project  I 
implemented a sketch for a basic HTTP REST API to the digital and analog pins of 
the Arduino that could be controlled using the standard Python urllib library.
- 3 -
2.5 pyusb/libusb
As  part  of  my  ongoing  Arduino/USB  shield  project 
(http://code.rancidbacon.com/ProjectLogArduinoUSB) I have developed an Arduino 
class  and  associated  Python  library  to  enable  communication  with  an  Arduino 
equipped with such a shield without driver installation.  It provides the following 
Python interface:
from arduino.usbdevice import ArduinoUsbDevice
theDevice = ArduinoUsbDevice(idVendor=0x16c0, idProduct=0x05df)
theDevice.write(0x01)
print theDevice.read()
This approach requires a customised sketch to be written for the Arduino but it can 
be of the form:
#include <UsbStream.h>
void setup() {
    UsbStream.begin();
    UsbStream.write(0xff);
}
void loop() {
  UsbStream.refresh();
  if (UsbStream.available() > 0) {
    int data = UsbStream.read();
  }
}
2.6 Bluetooth or Zigbee
With  appropriate  expansion  shields  it  is  possible  to  expand  the  Arduino's 
communication options to include wireless technologies like Bluetooth or Zigbee.
Existing Bluetooth Python libraries are available for use.
We will not consider either of these technologies further in this presentation.
2.7 Other options
The Arduino web site (http://www.arduino.cc/playground/Interfacing/Python) is 
updated with other more specialised or in development Python communication 
options.
3. Standalone Python microcontroller implementations
The Python/Arduino combination described above requires a host computer to run 
the Python interpreter—the Python code is not run on the Arduino itself. There are a 
- 4 -
number of projects that allow a standalone microcontroller to run Python code to 
varying degrees:
• python-on-a-chip (http://code.google.com/p/python-on-a-chip/)
• PyMite (http://wiki.python.org/moin/PyMite) predecessor of POAC
• Synapse SNAP and SNAPpy (http://www.synapse-wireless.com/)
• PyMicro (http://web.media.mit.edu/~nvawter/projects/pyMicro/)
Another possible  solution (not yet  implemented for Python to my (i.e.  Google's) 
knowledge)  is  the  approach  RAD (http://rad.rubyforge.org/)  takes  for  translating 
from Ruby to C.
4. Summary
There are many possible approaches to integrate Python and physical computing by 
way of the Arduino. The solution which enables the majority of the code to be 
written in Python is using python-firmata but other approaches have their 
benefits.
Most important of all is to remember that by adding Python and the Arduino to your 
toolkit you are no longer restricted to the virtual world. You too can now start 
charming the Real World™.
- 5 -


Not a member yet