File: orr.html

package info (click to toggle)
lg-issue113 1-1
links: PTS
area: main
in suites: sarge
size: 1,932 kB
ctags: 42
sloc: sh: 364; makefile: 34
file content (703 lines) | stat: -rw-r--r-- 34,935 bytes

<html>
<head>
<link href="../lg.css" rel="stylesheet" type="text/css" media="screen, projection"  />
<link rel="shortcut icon" href="../favicon.ico" />
<title>PyCon DC 2005 LG #113</title>

<style type="text/css" media="screen, projection">
<!--

-->
</style>

<link rel="alternate" type="application/rss+xml" title="LG RSS" href="lg.rss" />
<link rel="alternate" type="application/rdf+xml" title="LG RDF" href="lg.rdf" />
<link rel="alternate" type="application/atom+xml" title="LG Atom" href="lg.atom.xml" />

</head>

<body>


<img src="../gx/2003/newlogo-blank-200-gold2.jpg" id="logo" alt="Linux Gazette"/>
<p id="fun">...making Linux just a little more fun!</p>


<div class="content articlecontent">

<div id="previousnexttop">
<A HREF="oregan.html" >&lt;-- prev</A> | <A HREF="seymour.html" >next --&gt;</A>
</div>



<h1>PyCon DC 2005</h1>
<p id="by"><b>By <A HREF="../authors/orr.html">Mike Orr (Sluggo)</A></b></p>

<p>
<p> <a href="http://www.python.org/">Python</a>eers from around the world again
descended on George Washington University for the fourth annual <a
href="http://pycon.org/dc2005/">PyCon</a>, which was held March 23-25, 2005 in
Washington, DC. It's hard to decide what the highlight was: Guido's new beard,
the success of the Open Space sessions, the number of attendees (just shy of
450), the international scope (I saw several delegates from Germany, and a few
from Japan and Italy), the surprise sleeper hit (WSGI and integrating the web
application frameworks was the most discussed topic), the Python CPAN
(integrated with <a href="http://www.python.org/pypi/">PyPI</a>), the keynote
from Python's most prominent user (Google), David Goodger's name ("pronounced
like Badger but GOOD!"), or Guido's plans for static typing. ("Don't worry,"
he says about the latter, "it's just a bad dream.") 

<h3>Keynote #1: Python on .NET</h3>

<p> Jim Hugunin, who last year presented his paper on 
<a href="http://www.ironpython.com/">IronPython</a> (a version of
Python for Microsoft's .NET runtime environment), is now working for Microsoft.
("So I know if my computer crashes during this talk, I'll never hear the end of
it.")  Hugunin originally started the IronPython project to prove .NET was
unsuitable for dynamically-typed languages, but discovered the opposite.
IronPython on Windows .NET 2.0 Beta 1 is 80% faster than CPython (i.e.,
"normal" Python).  Why?  Different bytecode, support library is C#, and MS has
put a huge number of resources into optimizing .NET and its machine-code
compiler.  (IronPython on Mono "probably runs about as fast as CPython", he
said, although "this could improve with optimization".  Mono is a
Linux-compatible version of .NET.)  IronPython thus joins Jython (Python on
Java), Parrot (Python on Perl 6), and PyPy (Python on Python) as competitors to
CPython, meaning Python is now more a language specification than a particular
C implementation. 

<h3>Keynote #2: Python at Google</h3>

<p> Greg Stein from Google talked about why Python is one of their primary
development languages (alongside C++ and Java).  They found Python highly
adaptable, fast to learn, and easy to maintain.  Many of the Python modules
they use are actually <a href="http://www.swig.org/">SWIG</a> wrappers around C
libraries.  "We use lots of swigs." 

<p> Although only a few of Google's user-visible services are currently running
on Python (<a href="http://groups.google.com/">groups.google.com</a>,
<a href="http://code.google.com/">code.google.com</a>), Python is used
extensively in their infrastructure.  Google is a challenging environment to
administer because it has several servers.  "OK, a <em>lot</em> of servers."
How many companies do you know with a thousand servers to feed?  Their
development environment is written in Python: libraries that describe how to
build software, utilities to automatically run unittests and enforce a peer
review before code is checked in, and packaging systems.  Python lets
their tools evolve easily as hardware/software is upgraded. 

<p> Successfully checked-in code goes to a staging server, then to the "data
centers" which push it to the production servers.  All this is done in Python.
Other Python scripts monitor the production servers: Are they running?  Do they
think they're healthy?  Are their hard drives and CPU temperatures OK? 

<p> Google has released some Python code to the public, such as <a
href="http://sourceforge.net/projects/goog-goopy/">Goopy</a> (a "functional
programming" library).  They plan to release more, but slowly and
carefully.  Guido asked, "When are we going to see an open-source build
system?"  Greg said that it'll be as soon as they can convince the
management. 

<p> One interesting detail is that since Google always has a ton of user
queries coming in, they can test new servers/applications by simply diverting
1% of the traffic to it and seeing if they fall over.  (Steve Holden, PyCon's
coordinator, called that amount of traffic "frightening".)  The command-line
tool to do this is, of course, written in Python. 

<h3>Keynote #3: Guido van Rossum</h3>

<p> Somebody named Guido got up and talked about Python as if he owned it.
Rather than throwing cans of spam at him, the audience listened intently.  Why?
Because this was Python's creator, giving his annual address about the state of
the language.  After discussing "why my keynotes suck" (because he'd rather be
talking about the intricacies of language design), "why the beard", and "who
is my new employer" (<a href="http://elementalsecurity.com/">Elemental
Security</a>, a company developing an enterprise security product they won't
talk about, who also won't let Guido develop Python 3000 on company time),
Guido plunged into the controversies <em>du jour</em>.  

<p> How did the <code>@decorator</code> syntax win?  "Everyone disliked it
equally, it's unambiguous, it doesn't obscure the function definition, and it's
similar to Java."

<p> If function decorators are so necessary, why not class decorators too?
Metaclasses do the job well enough.  Other PyCon talks showed how metaclasses
are functions that tweak a class object after it's created; for example, to
make it keep a list of all its instances. To specify a class's metaclass, give
it a .__metaclass__ attribute or define a __metaclass__ variable in the module.
Or use a little-known feature of the <tt>type</tt> builtin to create a class on
the fly:

<pre>
type('MyClass', 
     (BaseClass1, BaseClass2),
     {'my_attribute': 1})
</pre>

You can also subclass <code>type</code> to make a class factory, as shown in
David Mertz's <a
href="http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html">tutorial</a> on
metaclasses.  

<p> Back to Guido's talk.  Python is getting more popular.  The Barton Group
did a survey of what their developer readers are using, and Python was at 14%.
The Barton Group described it as the "P" languages (Python, Perl, PHP) vs. the
"C" languages, and noted that Python has fewer security vulnerabilities than
Perl or PHP. Downloads and page views at <a
href="http://python.org/">python.org</a> are both up 30% from last year. 

<p> 2005 also featured Python's first security alert, against a vulnerability
in <code>SimpleXMLRPCServer.py</code>.  It's fixed in Python 2.4.1 and 2.3.5;
patches for earlier versions are <a
href="http://www.python.org/security/psf-2005-001/">available</a>.  The
experience showed that Python needed a Security Response Team, which is now in
place.  Previously there was no place to send a security alert without posting
it on a public forum or e-mailing it to Guido.  Now anybody can e-mail alerts
to <strong>security@python.org</strong>, and they will go to the entire response
team. 

<p> Python has gotten burned for putting out too many new features in minor
releases, so now only bugfixes will go into minor releases (e.g., 2.4.5), and
features will have to wait until a major release (e.g., 2.5).  The community
has indicated it wants a "slow growth" policy on features, with more focus on
stability and optimization. 

<p> Guido's employer won't let him work on Python on company time, so Python
3000 (a.k.a. Python 3.0) will not appear anytime soon.  But it now has a 
<a href="http://www.python.org/peps/pep-3000.html">PEP</a> describing the
direction it will go.  Python 3.0 will have backward incompatibilities as Guido
adds a few keywords, eliminates builtins he wishes he hadn't created, and
reorganizes the standard library into a deeper hierarchy.  Much of the CPython
code is still useful though, so it won't be a total rewrite.  Some features
will be backported to Python 2.x, sometimes accessible as "<code>from
__future__ import &lt;feature&gt;</code>".  Old-style classes will be eliminated in
3.0, as will <code>map/filter/reduce</code>.  <code>lambda</code> may be
replaced by anonymous code blocks, although a syntax has not emerged.
("Statements in curly braces was just a joke, really!")  

<p> Python 2.5 will have <code>any(iterable)</code> and
<code>all(iterable)</code> builtins; they both return booleans.
<code>any</code> tells whether any of the values are true, <code>all</code>
whether all the values are true. 

<h3>The Bad Dream</h3>

<p> Then Guido said, "If you don't like the next part, just pretend it's all a
bad dream."  Guido wants to add optional static typing to Python 3.0.  Here's a
possible syntax:

<pre>
def foo(a: int, b: list[int]) -&gt; list[str]
</pre>

This implies:

<pre>
    a = __typecheck__(a, int)    # Raises error if adapt(a, int) is false.
</pre>

If that horrifies you so much you want to switch to <a
href="http://www.ruby-lang.org/">Ruby</a> because "Guido is trying to turn
Python into C," don't worry.  He reassured us, "Nothing is settled yet!!!"
There are a number of unresolved issues:

<ul>
<li> We can't do compile-time checking because the arguments may come from
untyped code, so the checking has to be at runtime.  So he thinks <em>strong
typing</em> is a more accurate term than <em>static typing</em>.
<li> Strong types would work better with 
<a href="http://www.python.org/peps/pep-0245.html">interfaces</a> and 
<a href="http://www.python.org/peps/pep-0246.html">adapters</a>.
<li> <code>list[int]</code> may be shorthand for "an iterable of integer-like
objects" rather than strictly "a list of integers", since that's what most
functions mean when they ask for a list.
<li> Type checking is expensive to do on a mutable sequence, and there's no
guarantee a subroutine won't insert an incompatible type after the checking is
done.  So maybe the type information will be just documentation rather than
enforced, or maybe it will just be in interfaces, or maybe types will be
inferred rather than declared.
<li> He's afraid that even though type declarations will be <em>de jure</em>
optional, they'll become <em>de facto</em> mandatory if clueless tutorials
start falsely claiming that "declarations are always better".
<li> Other syntax proposals for the arguments are "<code>int a</code>" (like
C), "<code>a int</code>" (unambiguous because there's no <code>=</code>),
"<code>a as int</code>", "<code>a as integer</code>" (to show that any
int-compatible number is allowed).  Where does the default value go?  After the
whole thing.
</ul>

<h3>The PyWebOff and WSGI</h3>

<p> In the beginning there was <a href="http://zope.org/">Zope</a>.  Zope was a
web application framework and the basis for several Content Management Systems,
but it had some discontents who dared to call it "monolithic" and "unpythonic".
And behold, then there came <a
href="http://www.webwareforpython.org/">Webware</a>, and it was Modular and
didn't impose New Programming Languages on site developers, and there was much
rejoicing.  But others rebelled at even Webware's Heavy-Handedness and arbitrary
Conventions and wanted something even Simpler, and a Ton of frameworks
appeared: <a href="http://www.mems-exchange.org/software/quixote/">Quixote</a>
(which calls itself "lightweight Zope"), <a
href="http://skunkweb.org/">SkunkWEB</a> ("Smell the power!"), 
<a href="http://cherrypy.org/">CherryPy</a> ("fun to work with"), and some
<a
href="http://www.python.org/moin/webprogramming#head-a8b5de8b5a80f031b52613896de9aca91194159f">thirteen
others</a>.  Meanwhile, <a href="http://twistedmatrix.com/">Twisted</a> had
released its own Whole Earth Catalog of asynchronous Internet libraries
including <a href="http://nevow.com/">Nevow</a>.  Trying to find the forest
through the trees, Ian Bicking held a <a
href="http://colorstudy.com/docs/shootout.html">Shootout</a> at PyCon 2004,
comparing several frameworks against each other. 

<p> This year, Michelle Levesque went a step further and said we've forgotten
about "Brian". "Brian" is the typical non-techie developer who just wants to get
a simple dynamic site up.  The Python frameworks have now mushroomed to forty
[slide showing a montage of logos].  Experienced Pythoneers know that Zope is
easy <em>if</em> it does what you want out of the box, Quixote is good for
sites that are big on calculations and small on eye candy, Twisted is good for
high-demand sites, etc.; but Brian doesn't know this. Brian sees forty
apparently equal frameworks and chooses this: [slide with the word "PHP"], or
maybe this: [slide with the word "Java"].  Python is about having One Obvious
Way To Do It, but in the web framework world it's Ruby and Java that have a
unified model, not Python.  Quoting Moshe Zadka, "You're not a Real
Python Programmer until you've written your own web templating toolkit."  But,
Michelle said, there are a lot of Brians in the world; they form by far the
biggest potential "market". 

<p> Michelle's plea to developers is, "Stop writing kewl new frameworks! Help
improve the top few frameworks so they can become a best of breed. And put
documentation on python.org telling Brian, "For heavyweight use A, for
lightweight use B, for performance use C, for XML use D, for no XML use E."  Of
course, this means the Python community must come to consensus on which
<em>are</em> the top frameworks.  Some might think "when hell freezes over",
but Michelle has a plan. 

<p> She issued herself a <a
href="http://pyre.third-bit.com/pyweb/index.html">challenge</a> to implement a
typical Brian application (in this case, a book checkout system) in each of
seven frameworks, and compare the experiences (i.e., compare the grief).  She
also blogged her thoughts along the way, making this perhaps the first PyCon talk
with its own <a href="http://pyre.third-bit.com/pywebblog/">blog</a>.  Of
course this is just one person's opinion, but it serves as a starting point for
discussion. 

<p> Ian Bicking followed Michelle's talk with a remarkably similar topic: "WSGI
Middleware and WSGIKit (for Webware)".  He 
<a href="http://blog.ianbicking.org/why-web-programming-matters-most.html">agrees</a>
with Michelle that the proliferation of incompatible web frameworks is the most
important issue preventing Python from enjoying the huge growth curve of PHP,
but he takes a different approach.  Rather than just writing documentation, Ian
would like to see these frameworks become interoperable.  <a
href="http://www.python.org/peps/pep-0333.html">WSGI</a> (the Web Server
Gateway Interface) is a proposed standard for Python (PEP 333).  It's a
protocol for web servers to communicate with application frameworks.
Currently, each framework has to come with a whole slew of adapters (CGI,
FastCGI, mod_python, a custom module, a standalone HTTP server) to communicate
with Apache.  WSGI allows each framework to need only a single virtual adapter,
and the webservers can provide "best of breed" adapters that plug into any
WSGI-compliant framework.  You can also plug in single-purpose "middleware"
objects that look like an application to the webserver, and like a server to
the framework, or even chain middleware objects together.  This could allow
alternate URL-parsing and Session modules to be plugged in and out, for
instance, eliminating the need for each framework to reinvent the wheel, and
allowing applications to mix and match which coding styles they prefer (e.g.,
WebwareRequestObjectMiddleware vs QuixoteRequestObjectMiddleware).  

<p> Ian refactored Webware to make it WSGI compliant.  Webware in this
environment turned out to be a pretty thin layer over the standard protocol.
Why use Webware at all then?  One, to support existing Webware applications.
Two, because some developers prefer the Webware servlet style.  WSGI isn't
meant to be used directly by application developers; its dict-function-iterable
model is inconvenient for that.

<p> Since there are two models for concurrency, applications would have to
check the 'wsgi.multithread' and 'wsgi.multiprocess' keys (boolean) and take
appropriate action depending on which style the web server is using.  

<p> These two talks sparked a lively debate in Open Space sessions and at
lunch tables about whether such integration between the frameworks is (A)
necessary and (B) desirable.  Dissidents argued that "everyone's going to have
their favorite no matter what you do", "common design patterns are more
important than common implementations", and "it's not that important".  Several
people started collaborating to make their favorite frameworks WSGI compliant
(most notably Quixote and <a
href="http://aquarium.sourceforge.net/">Aquarium</a>).  However, the discussion
also showed that people have widely differing opinions about what WSGI goals
are worth pursuing and how the proposed "middlewares" should behave.  This will
be followed up on after PyCon.  It's too bad that nobody thought to organize a
sprint for this.  (Sprints are group hacking sessions that occur before or
after PyCon.)

<p> Donovan Preston ("the Nevow guy") followed Ian's talk and showed how Nevow
can encapsulate the Javascript needed to send little messages between the
client and server; e.g., to update widgets on a form without redrawing the
entire page. 

<h3>Other Talks</h3>

<p> Michael Weigend spoke on "eXtreme Programming in the Classroom".  Weigend
has been using XP and Python to teach programming to school children.  (XP is
the abbreviation for eXtreme Programming; it's not related to Microsoft's
operating system of the same name.)  In XP, the developers have to gather
"stories" -- use cases and usage examples -- from the user.  Then they have to
choose a metaphor for their application, in this case a text editor and chat
room for nine-year-old students in Germany learning English.  So it might have
pop-up lists for common responses, for instance.  The developers then explore
implementation tools (e.g., GUI libraries) and make time estimates.  Then they
choose a "story" to work on, a piece small enough to do just one thing, and
split into pairs to each write an implementation of the story.  Then they
gather and select the best implementation.  After all the stories are thus
implemented, they integrate the best implementations together.  That's one
iteration, which may take a week.  Then they evaluate the integrated product:
does it work right?  does it really fulfill the stories?  If not, iterate again
to come up with a better implementation.  The beauty of this method, Weigend
says, is "the project is always a success".  Even if you have to stop work on
it early, at least it does something useful, even if it doesn't fully comply
with all the stories.  In contrast, with linear software engineering, if you
stop the project early you may have nothing running at all. 

<p> Holger Krekel introduced 
<a href="http://codespeak.net/py/current/doc/test.html">py.test</a>, a tool
I've been avidly using recently.  It's like <code>unittest</code> but simpler
and more flexible.  You merely write functions with assert statements, and pass
your module to the command-line tool.  There are a few support functions to
handle cases like "this test should raise this exception" and "I want some
common code executed before each test".  Test cases can also be iterative:

<pre>
def func(x, y):
    assert ...

def test_more():
    for (x, y) in [(1, 2), (1000, 2), (0, 0)]:
        yield func(x, y)
</pre>

<code>test_more</code> is a test function because it begins with "test_".  But
it's also a generator that calls another function with a different set of
arguments each time.  This is useful for testing boundary cases in your other
function (<code>func</code>).  There's an option to automatically drop to
<code>pdb</code> (the Python debugger) on any failure.  There's also a sessions
feature that runs the remaining failed tests as you edit and save each
offending module.

<p> One session summarized the sprint activity this year.  
<a href="http://www.osafoundation.org/">Chandler</a> fans experimented with a
plug-in API and did three projects.  
<a href="http://www.gnu.org/software/mailman/">Mailman</a> fans worked on
Mailman 3, a SQL database back end, and started using 
<a href="http://sqlobject.org/">SQLObject</a>.  
<a href="http://www.zope.org/Wikis/ZODB/FrontPage">ZODB</a> fans added BLOB
support and an iteration API.  Zope 3 developers worked on a weblog object
using Dublin Core metadata.  A Python Core team worked on an AST step for the
Python compiler.  And <code>distutils</code> fans did <em>phenomenal</em> work,
finally implementing the long-desired Python CPAN.  They took the 
<a href="http://python.org/pypi/">Python Package Index</a> and added file
upload, so that it could store the packages themselves as well as pointers to
them.  By the way, the coordinator said PyPI is pronounced "pippy", not
"pie-pie".  "Pie-pie" sounds identical to PyPy.  But old habits die hard.  I'm
used to saying "pie-pie", just like I say "line-ux" instead of "linnux" most of
the time.  (I still remember when Linus spoke at LinuxExpo in 1998 and called
himself Line-us and the OS Linnix in the same sentence!) 

<p> Richard Jones gave a talk about an excellent product, 
<a href="http://roundup.sourceforge.net/">Roundup</a>, an issue tracker with
web, e-mail, and command-line interfaces.  I'd used TkGnats a few years ago and
was happy to learn that Roundup has acquired Gnat's most important features but
with a slicker interface.  Sending it an e-mail creates a new issue or attaches
the message to the existing issue.  The main page shows you immediately which
issues are open, and you can set categories, priorities, and keywords, and save
custom searches.  It can use several database backends and comes with a
no-hassle demo.  

<p> Mike Salib didn't have the feistiness of last year's Starkiller talk, but
his "Stupidity and Laser Cat Toys: Indexing the US Patent Database with Python
and Xapian" talk had nothing to do with sophisticated cats and everything to do
with taking on the software patent cartel.  His battle cry is, "The patents
will kill us all; there's more of them than there is of us.  They reproduce a
lot.  Sooner or later, people will die due to lack of access to patented
technology."  

<p> The US patent database can be downloaded on the web, but only one patent at
a time.  Downloading more than a hundred per session is forbidden, but you can
have all patents conveniently delivered to your door on tape for the low price
of $30,000.  Mike didn't have $30,000 so he opted to download them a hundred at
a time in parallel from several computers at the lab of a university that shall
remain nameless.  The files come to several gigabytes compressed, which Mike
was giving away on DVD to any who asked.  He will soon have a website up at
<a
href="http://divmod.org/users/msalib/patents/">here</a>.


<p> Mike considered using pyLucerne but it was too slow.  (However, other
projects at the conference are using pyLucerne and are happy with it.)  He
chose Xapian because it works with compressed databases.  There were many build
issues, but Mike has written a library that will make it easier for others.
I'm not sure if it's been released yet, though. 

<p> Anna Ravenscroft spoke on "The Time of Day": how to get Python to tell you
the current time in any timezone.  This was especially apt for her since she
was in the process of moving from Italy to California, and had stopped in DC
for the conference.  Her poor little laptop just couldn't keep up with her
jet-set lifestyle.  Getting the time in Python 2.4 or 2.3 is simple:

<pre>
$ python
Python 2.3.3 (#1, Aug 19 2004, 17:24:27)
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
&gt;&gt;&gt; from datetime import datetime
&gt;&gt;&gt; print datetime.now()
2005-04-01 11:48:54.392067
&gt;&gt;&gt;
</pre>

Formatting the time seems to fluster some people that try to use
<code>time.strftime()</code> with <code>datetime</code> objects, but that's
easy too:

<pre>
&gt;&gt;&gt; print datetime.now().strftime("%B %e, %Y %l:%M%P")
April  1, 2005 11:53am
</pre>

For date calculations Anna recommends <a
href="https://moin.conectiva.com.br/dateutil">dateutil</a>, and for a database
of timezones <a href="http://pytz.sourceforge.net">pytz</a> <code>pytz</code>.

<p> Andrew Jonathan Fine described how he saved his company a million dollars
by writing a Python - DocBook SGML - OpenJade - RTF converter to extract the
text and structure from MS Word documents in diverse formats into a standard
report format that was also in Word.  That saved 7 FTEs over two years to
manually format it, dwarfing the cost of researching DocBook, Word libraries,
etc.  

<p> These are just a few of the <a
href="http://www.python.org/pycon/2005/schedule.html">talks</a> presented at
PyCon. 

<h3>Open Space</h3>

<p> Last year's Open Space suffered from a lack of promotion.  People didn't
realize it was happening, didn't look at the schedule to find sessions of
interest, and couldn't remember what Open Space was supposed to be or how it
differed from Birds of a Feather (BoF) sessions.  This year Jim Fulton vowed 
to make it better, and he did.  BoF's were collapsed into Open Space, and half
the sessions on the first day were prescheduled so that at least some choices
would be there.  One room was devoted to Open Space for the entire conference
(except keynote talks), and another room was devoted half time.  

<p> So what is Open Space?  To do a regular talk at PyCon you have to present a
paper to the vetting team who may or may not accept it.  To do an Open Space
you simply sign up on the schedule.  Open Space sessions are smaller, typically
5-15 people.  They may be a presentation or a roundtable discussion.  

<p> The interesting thing this year was the number and quality of Open Space
sessions.  Almost every time slot was filled, and many sessions were as
content-ful and worthwhile as the main talks.  In fact, some <em>were</em> main
talks last year, repeated by popular demand. 

<p> Brett C. gave a particularly interesting Open Space talk on "How Python is
Developed".  The python-dev team is the implementation group, with 10-12 core
developers.  Eighty people have checkin rights, but many have not touched the
code in years or only work on certain modules.  New modules, by BDFL
pronouncement, must first be widely adopted by the Python community before they
can get into the standard library, must adhere to the BDFL's coding
conventions, and the developer has to commit to maintaining it. 

<p> There are plenty of ways to contribute to the Python Core without being a
high-level programmer.  Post bug reports, run the regression test suite on
various platforms, use the beta versions.  Install patches posted on
SourceForge, run the regression tests on them, check the code to make sure it
looks OK, and post the results back to the patch thread.  Martin van L&ouml;wis
also has a deal for those who really want to get a certain patch into Python.
Do five reviews of other patches, say you did on the python-dev list, and
Martin will make sure to consider your favorite patch. 

<h3>Lightning Talks</h3>

<p> Another highlight this year was the Lightning Talks.  These were
spontaneously scheduled like Open Space, but limited to five-minute
presentations.  Some of the speakers weren't as polished as the prepared talks,
but the content was nevertheless high quality.  The first session had forty
talkettes; the second around ten.  Somebody came up with the simplest
explanation of continuations I've seen:

<pre>
&gt;&gt;&gt; def foo():
...     a = 5
...    def bar():
...        print "The value is", a
...    return bar
...
&gt;&gt;&gt; f = foo()
&gt;&gt;&gt; f()
The value is 5
&gt;&gt;&gt;
</pre>

This is a continuation because <code>a</code> is defined in the surrounding
scope, and even though it's a local variable in the enclosing function, it
nevertheless remains alive when <code>bar</code> is called. 

<p> Other talks were on the need for a <code>Money</code> type 
subclassing <code>Decimal</code>, and active command line completion.
<code>rlcompleter2</code> works in the Python shell and 
<a href="http://ipython.scipy.org/">ipython</a>, and shows object names,
function signatures, docstrings, and even source code. 

<h3>Miscellaneous</h3>

<p> Stephen Diebel held a Q&amp;A on the Python Software Foundation, which
holds Python's copyright, takes care of legal issues, and is a tax-deductible
fundraiser.  This year they've awarded $40,000 in grants to three projects: one
to upgrade Jython's features to 2.4, another to revamp python.org to make it
easier for people to contribute news, and another I didn't catch.  Much of the
money came from the proceeds of past PyCons.  This will be more difficult to
sustain as PyCon grows, because bigger venues mean bigger expenses, and a dud
year could wipe out the surplus.  But Diebel is pretty confident the grant fund
will grow, and maybe in the future they can pay a couple of the core developers
to work on Python full time. 

<p> The PSF members introduced themselves as "Uncle Timmy", "Nephew Jeremy",
"Uncle Guido", "Just David", "Neil", "Martin", and "Steve".  Somebody
complained the PSF was America-centric, but Martin van L&ouml;wis pointed out that
he is not American, and many of the grants have been going to other places.
The <a href="http://europython.org/">EuroPython</a> organizers asked for a PSF
representative to come speak, since most EuroPython attendees don't know the
PSF exists. (EuroPython will be in G&ouml;teborg, Sweden on June
27-29.  Next year it will be at <a href="http://www.cern.ch/">CERN</a> in
Switzerland.)

<h3>Plans For The Future</h3>

<p> Congratulations to the honorable Steve Holden, who is retiring from PyCon
chairmanship after several years and whose final stunt was pulling off the best
conference yet.  Andrew Kuchling has taken the baton for 2006, and gave an Open
Space talk about his preparations.  He noted how PyCon has spontaneously
increased in size every year in spite of our pitifully lame attempts at
promotion, and at 440 we've already maxed out the capacity of GWU.  Next year
we have to plan for 500-600.  Since most attendees are cheapskates and won't
pay more than $70 for a hotel room, we'll likely have to move out of DC to find
an affordable venue that can accommodate future expansion for several years.
The most likely location at this point is Baltimore.  It will probably be
someplace "near DC" since that's where many PyCon organizers live, and other
regions haven't gotten off their butts to follow up on local venues. 

<p> The most common request on last year's feedback forms was more
tutorial-level activities.  Without much conscious thought, PyCon has
positioned itself as a "research conference" where most talks are about
cutting-edge projects.  That's good for advanced users but doesn't meet the
continuing need to train the new generations of users that are dabbling in
Python.  Suggestions include more talks on basic topics, repeating tutorials
that people have written for their local groups, having intense (perhaps paid)
tutorials before the conference, and classifying the talks as
beginner/mid/advanced on the schedule.  They're also considering a low-cost
teenager track on the last day with basic topics, which has perked the interest
of a couple local schools that use Python in class. 

<p> We made one attempt to fill in the tutorial gap this year, but it fell
flat.  I organized an Open Space called "Python Q&amp;A".  I was trying to
do something like <a href="../tag/ask-the-gang.html">The Answer Gang</a>
here at the Linux Gazette, where people could bring any Python-related
question, but we ended up with all answerers and no querents. We'll have
to try a different approach next year, perhaps doing it right after a
tutorial track.  

<p> In the sprint reports session, Andrew gathered suggestions for next year's
sprints. Most people said four days was a good length but they should be after
the conference rather than before, so that people could sprint on what they
learned at the talks. PyCon would have to move to Monday-Wednesday to
accommodate the sprints afterward; otherwise, people from overseas would have
to take 1 1/2 weeks off work to attend them.

<p> See y'all next year. 


</p>


<!-- *** BEGIN author bio *** -->
<P>&nbsp;
<P>
<!-- *** BEGIN bio *** -->
<hr>
<P>
<IMG ALT="picture" SRC="../gx/2003/authors/orr.jpg" WIDTH="235" HEIGHT="333" ALIGN="left"  HSPACE="10" VSPACE="10" class="bio">
<em>
Mike is a Contributing Editor at <I>Linux Gazette</I>. He has been a
Linux enthusiast since 1991, a Debian user since 1995, and now Gentoo.
His favorite tool for programming is Python.  Non-computer interests include
martial arts, wrestling, ska and oi! and ambient music, and the international
language Esperanto.  He's been known to listen to Dvorak, Schubert,
Mendelssohn, and Khachaturian too.
</em>
<br CLEAR="all">
<!-- *** END bio *** -->

<!-- *** END author bio *** -->

<div id="articlefooter">

<p>
Copyright &copy; 2005, Mike Orr (Sluggo). Released under the <a
href="http://linuxgazette.net/copying.html">Open Publication license</a>
unless otherwise noted in the body of the article. Linux Gazette is not
produced, sponsored, or endorsed by its prior host, SSC, Inc.
</p>

<p>
Published in Issue 113 of Linux Gazette, April 2005
</p>

</div>


<div id="previousnextbottom">
<A HREF="oregan.html" >&lt;-- prev</A> | <A HREF="seymour.html" >next --&gt;</A>
</div>


</div>






<div id="navigation">

<a href="../index.html">Home</a>
<a href="../faq/index.html">FAQ</a>
<a href="../lg_index.html">Site Map</a>
<a href="../mirrors.html">Mirrors</a>
<a href="../mirrors.html">Translations</a>
<a href="../search.html">Search</a>
<a href="../archives.html">Archives</a>
<a href="../authors/index.html">Authors</a>
<a href="../contact.html">Contact Us</a>

</div>



<div id="breadcrumbs">

<a href="../index.html">Home</a> &gt; 
<a href="index.html">April 2005 (#113)</a> &gt; 
Article

</div>





<img src="../gx/2003/sit3-shine.7-2.gif" id="tux" alt="Tux"/>




</body>
</html>