2005-04-23

Five Googlers all in a row: Jeremy Hylton, Greg Stein, Alex Martelli (who started at Google the following Monday!), Chris DiBona, and Will Robinson. Posted by Hello

2005-03-27


Daniel Chudnov Posted by Hello

Christian Theune reports on his sprint work on blob support in ZODB. Posted by Hello

Holger Krekel gave a lightning talk on rlcompleter2. The rule for its use is just keeping hitting tab. I asked if he hit tab often enough if it would bring up the source code. He hadn't planned to demo that, but he did it on the file. Very cool. Posted by Hello

Peter Kropf Posted by Hello
gave a lightning talk on his 7,000-mile motorcycle trip across North America. He packed a custom computer and video camera and programmed it with Python.

Tim Peters Posted by Hello

Greg Stein Posted by Hello

Jim Hugunin. Posted by Hello

Steve Holden. This was Steve's last year as PyCon chair after getting the whole thing started three years ago. Posted by Hello

Martin von Loewis, Armin Rigo, and Perry Greenfield Posted by Hello

Ian Bicking sips coffee. I finally got a chance to talk to Ian on the metro as we both headed home. Posted by Hello

Richard Jones (Roundup and PyPI), Barry Warsaw (Mailman), and Andrew Kuchling (Quixote). They are the members of the newly formed PSF infrastructure committee, which will manage python.org. Posted by Hello

2005-03-25

More lightning

After yesterday's great lightning talks, I was looking forward to today's talks as well. They didn't disappoint.
  • Ka-Ping talked about creating antigravity in his dorm room. Awesome.
  • Some really cool Python and hardware hacks from Peter Kropf as he went on a two-month motorcycle road trip across North America.
  • Wai Yip Tung's MindRetrieve does cool personal web history search using PyLucene. Looked kind of like Google Desktop's search of your web history, except that it's cross-platform and focuses just on web history search.
  • Someone whose name I didn't catch (sorry!) showed us the Canary Database, which does neat work for libraries and also uses PyLucene. Made me pretty sorry that I missed the PyLucene talk earlier today.
  • And plenty more...

The Round Table

A group of us went to dinner at Logan Tavern last night. Guido van Rossum, David Ascher, Jeremy Hylton, Will Robinson, Chris DiBona, Barry Warsaw, Matt Blecker, and myself. We sat at a big round table which normally helps for discussion in a group, but the noise level was pretty high.

The conversation was quite interesting. It started with a query about whether a well-known Python app should be hosted by the Apache Software Foundation (ASF) or the Python Software Foundation (PSF). On one hand, the ASF is better structured and ready to accept new hunks of software. It has guidelines, procedures, and all the various "stuff" to process incoming software and to get the associated development group integrated with the rest of the ASF. It also provides version control and distribution points and all the other bits for running a project. The PSF doesn't have any of this. It only manages Python, and it does that on SourceForge rather than a PSF infrastructure. So what to do with the Python app?

Moving into a PSF project would be sort of a forcing function. It would lay the path for other projects to follow. That could be very good for the PSF.

But the discussion at the table then became, "but should the PSF do that? What should the PSF be? Why is that important?" It was a lot of fun to watch David and Guido go back and forth on the issue. Guido really doesn't care much for doing a lot of PSF stuff -- he just wants to work on the Python language. David wants to see the PSF role and visibility increased (so do I, fwiw).

It's an interesting question for the PSF Members to talk about. We didn't decide where to put the app (ASF or PSF), but I don't think that is something that needs to be solved right away.

Dinner was quite good, btw, even though the guy next to me was literally half my age ;-)

Greg's keynote: "Python at Google"

Although I'm admittedly biased, I really enjoyed Greg's talk this morning on "Python at Google." He covered the wide spectrum of Python use at Google and left plenty of time for questions at the end.

Some of Greg's talk (and many of the questions) focused on Google's use of SWIG to Pythonize our C++ libraries in a fairly hands-free way. As Greg aptly put it, "SWIG is pretty underrated." Questions from the audience focused on SWIG performance and robustness, especially when confronted with heavily templatized C++. People also mentioned alternatives like Boost.Python and PyCXX. One audience member who had used all three systems commented that Boost had been great for supporting templates, but that its generated .so files were 10x bigger than equivalent ones from SWIG. Still, I'd like to learn more about these systems.

Greg's actually standing in a small knot of people about 20 feet in front of me, still engaged in some heated, SWIG-related debate. :)

Greg also touched on Google's open-source efforts centered around code.google.com, and I was pleased to hear some positive audience feedback and some questions about what Google plans to open-source next.

Neal Norwitz, Raymond Hettinger, and Fred Drake. Raymond was one of the people I got to meet for the first time at PyCon -- a real treat. Posted by Hello

SchoolTool sprinters, including the Elkners and Mike McLay Posted by Hello

Bruce Eckel, Allen Short, and Andy Wright.

Final day of PyCon sprints. This room held sprints on Twisted, SchoolTool, Zope, and ZODB. Posted by Hello

Fred Drake and Stephan Deibel Posted by Hello

Christian Tismer. The photo tempts me to make a joke about continuations, but I'll resist. Posted by Hello

Aaron Lav: "I've wanted a user-space NFS server in Python since I was a child." Posted by Hello

Ka-Ping Yee Posted by Hello

David Ascher and Facundo Batista with laptops, and a roomful of people listening to a lightning talk. Posted by Hello

Roger Masse Posted by Hello

Will Robinson Posted by Hello

Ba-dunk-a-dunk. Done-da-da-day.

Another day past. Lots of interaction, and lots of greets with some peeps that I haven't seen for (in some cases) five years or more. An interesting aspect to the conference is what happens *outside* the conference. Stop and consider... we have a big schedule of talks. Great. But count heads. People aren't going to all the talks.

This is where PyCon shines. They have defined some "open spaces" where people can define some loose talks, presentations, or light tutorials. A very unstructured system that "fills in the blanks". They get up in front and yammer on for five minutes. Lest you think I'm going funky on people with the word "yammer"... yes, I got up and yammered about EZT. Not sure that I was any more successful about escaping the "yammer" marking.

So that big group that might not have a chance to talk? Well... they do. There were lots of avenues. Heck, we got a venture capital talk from a VC guy during the lightning talks. Is that normal for a geek conference? No. So expression... good. That rocked.

Well... foo. Time for sleep. Got a talk in the morning :-)

The rest of PyCon, day #2

I spent much of the afternoon at the lightning talks that Greg mentioned, and they were great fun. The two things that struck me most were:
  1. The fact that one or two people can hole themselves up for a while, churn out a bunch of Python code, and generate some pretty cool hacks (a userspace NFS fileserver, a really neat threaded email viewer, etc. etc.)
  2. The incredible warmth of the community. Person A might not care too much about web stuff, but he or she is still genuinely excited and supportive when Person B gets up to give a 5 minute lightning talk on his/her Python web templating library.
After the lightning talks, I went to three more heavy-duty, guts-of-the-language type talks. Two were by Alex Martelli, and the third was from Mike Fletcher.

Alex's first talk centered on descriptors, decorators, and metaclasses. It seemed like a great 1-hour talk that had been squeezed into 20 minutes; if (like me) you didn't know much about descriptors before the talk, then it probably would have made you curious to learn more, but there just wasn't time to absorb much of what Alex was saying.

Alex's second talk was a much more accessible spiel about generators and iterators. Alex took us smoothly from introducing basic generator syntax up to introducing more complex, nested generators for things like tree traversal. He also made a great pitch for itertools, citing its elegance and high-level nature as a motivation for many people, and the fact that itertools are fast as a great motivation for the remaining, more pragmatic Python programmers. :)

Mike's talk also focused on descriptors and related language constructs, but some technical difficulty with his slides made things a bit tough. I did have a chance to speak with Mike for a while in the evening, and when I was praising the Traits talk from the day before, he mentioned a few other projects that are doing similar things (many of them using descriptors). He pointed me to wxOO/BasicProperty/BasicTypes and PEAK, and he said that Zope had something along those lines as well. (I might be forgetting one more). Mike had personally worked on the wxOO project, and he said that BasicProperty and BasicTypes had some web support, which is something that's currently missing from Traits.

2005-03-24

Zappity Zap!

Sitting in the Lightning Talks session right now. There is some very cool stuff. Ka-Ping's screen scrape and navigation stuff is very slick. It is neat for poking around a site and a page. It basically keeps a context of where you are, and you can nav forward/backward. It even has bits for submitting forms and whatnot. I pointed out my friend's module, Beautiful Soup, to him to check out.

Richard Jones showed off some funky Ducks game that came out of a "code up a game in 48 hours" competition. He also briefly demoed PyPI ("pippy"), a new Python software repository which supports upload.

There was also a userspace NFS daemon. Woah!

Lightning talks are always so much fun because of the random nature. People pull out all their neat little bits to demo. Stuff that isn't "big enough" to turn into big, official projects. Lightning talks give you a way to look behind the curtain to see all the stuff that is really going on out there.

"Perl isn't all bad."

Jeremy beat me to the punch again in describing today's keynote. Here are some quick highlights from my point of view:
  • @decorators are here to stay, and Guido thinks that knee-jerk reactions against Perl-like syntax is silly. (That's where the quote in the title comes from).
  • Python's popularity has grown over the past year (the Jolt award, complimentary articles and studies, 30% higher traffic on python.org).
  • Python 3000 is coming someday (probably). But Guido's committed to a slow growth policy. He really wants to avoid pulling a Perl 6.
  • The discussion of static type checking was interesting. Guido's current thought (presented as "strawman syntax" and "strawman semantics") looks like convenient shorthand for user-dictated runtime type checking:
    def foo(a: int, b: list[int]) -> list[str]: ...
    means:
    def foo(a, b):
    a = __typecheck__(a, int)
    b = __typecheck__(b, list[int])
    r = __original_foo(a, b)
    return __typecheck__(r, list[str])
  • He acknowledges that there are lots of tricky issues with this scheme, including efficiency problems with things like checking the type of a list. He also agreed that "static type checking" is no longer the right name for what he's proposing.

Facial hair, functional programming, and static typing

We arrived at Guido's keynote in time for him to explain why he had a beard. He started it because he wanted to shave a few minutes off his schedule during a beta crunch, but he kept it because he liked having his co-workers call him professor.

There was a brief discussion about decorators -- why @prefix syntax won and why there are no class decorators. I thought the choice was obvious given the candidates last year, although I didn't mind the C# syntax either.

Signs of Python's popularity: InfoWorld survey shows python use grew to 14% from 8% the year before. Burton Group wrote a report in "P languages" that recommended the use of Python. Python won a Jolt productivity award -- the runners up honor. We discussed what to make of the 14% statistic a few months ago; based on an gross estimate of the number of programmers survyed, it seems like there are 750,000 to 1 million Python programmers. (Some other back-of-the-envelope estimates come up with the same result.)

Python now has a Python security response team. Guido has subscribed to the bugtraq list. It was interesting to hear him acknowledge that security was a serious issue. He used to be completely uninterested, because, I think, he didn't expect a random attack to have any effect on him.

Guido started talking about Python 3000 in 2000. He said he always imagined it as a release that was three years off, and it still feels that way. He maintains, though, that Python 3.0 will be incompatible in several ways: new keywords, some builtins removed, "classic classes" removed. He said we're not going to do a Perl 6 for Python, which lead to some applause. "Because we didn't get it so wrong the first time," he said.

Guido plans to focus on changes to the language and library, but not the implementation. There are a ton of people working on CPython and other Python interpreters on other virtual machines.

Guido talked a bit about functional programming -- adding any and all builtins to Python 2.5. He discussed any() at length, because he decided it will be a predicate and not a function that returns an element from the sequence.
def any(iter):
for elt in iter:
if elt: return True
return False
It seems to me that any() should return an element of the sequence or None, which isn't an option Guido discussed. None could never by an element returned from the sequence, because it is False. It makes sense for the empty sequence, which was one case Guido worried about. At the end of the day, any() is so short that it is easy to write your own.

It's seems uncontroversial to remove map, reduce, and filter, perhaps leaving them in an extension module. It's quite a different issue to remove a lambda. One option is to find a way to define anonymous code blocks, although most of the uses of anonymous code blocks in Ruby correspond to uses of generators and yield in Python. I think the key issue isn't whether we can make the function anonymous, but that you can write a function in an expression context. Guido later commented that the naming issue wasn't very important.

Guido talked a little about Numeric issues, which don't hold my attention. Tim Peters and Eric Jones had an extended conversation about Numeric at lunch. There are a wide range of user expectations: Should divide by zero raise an exception or return infinity and should it print a warning? The decimal module gives all three options, but getting consistent behavior for these issues across all platforms is really difficult. C89 and C99 don't provide any useful guarantees about numeric issues, so Python's implementation doesn't have a good place to start. (It's ironic because, as Tim noted, all hardware has implemented IEEE 754 since the mid 80s. We just don't have language or library support for accessing the hardware features.)

Guido's current thinking about "static typing" is that programmers could write type annotations that would check types at runtime or even coerce ("adapt") an object from one type to another.

"My favorite classic programming language is Pascal." The very limited support for nested functions in the original Python stem from one of the things he didn't like about Pascal. (Dave Hanson wrote a paper on the same issue: Is Block Structure Necessary?.)

"On form of adaptation or another will make it into 2.5 or 2.6."

He discussed typechecking and generics, but didn't have a practical scheme for checking generic types at runtime. One suggestion was to use it only for documentation, but that seems pointless to me. If the documentation isn't automatically checked, it will be wrong some of the time. The fact that there is tightly integrated syntax won't help at all in this respect. To my mind, if the typechecking doesn't check some static property of your code, I'm not interested in it.

Guido: I'm still interested in exploring this feature, but it's far from clear that it will go into the language.

There was lots of applause for the suggestion that we focus less on type annotations and more on type inference. I think that's an odd position to hold, because it finesses the hardest problem -- the actual type system. What kind of types do you try to infer for a program? What kind of errors are you trying to detect statically?

Afternoon talks

I went to five more talks in the late afternoon and early evening. (Didn't think it was possible, but I'm almost Pythoned out!) Of the talks from the afternoon, these stand out:

Design Patterns and Python OOP: Objects by Design
Alex Martelli

Although the content was pretty redundant with some recent reading and discussion of design patterns I've been doing at work and at home, it was fun to see the Python in a Nutshell author speak in person. He went over some patterns like Strategy, State, and NullObject, showing how to implement them in Python. He gave the standard pitch for preferring composition to inheritance. In one twist, he made a distinction between two types of composition in Python:
  1. holding, which basically means public exposure of a contained object and its methods/attributes. (outer.contained.Foo())
  2. wrapping, which means exposing the desired functionality of the contained object through wrappers, and keeping the contained object itself private (outer.Foo(), which might call outer._contained.Foo())
Alex argued that we should prefer the second mechanism over the first, since that hides implementation details from our clients, freeing us to change the implementation in the future, etc. etc. I found this whole discussion kind of funny, because all the arguments for preferring "wrapping" over "holding" in Python are the same arguments for avoiding the use of public data members in, say, Java. It's just that in a language like C++ or Java, there's a long and hallowed tradition of "public data members == BAD" that no one even needs to speak about. I'm still new enough to Python that I don't know where the current culture and coding conventions came from. But I'm happy to see that there's little fundamental disagreement on sound OOP design principles across languages.

Alex also showed a couple of neat State implementations that work by changing __class__ or by rebinding individual methods. IIRC, the Gang of Four briefly mentioned such capabilities in languages like Self and Python when they were describing the State pattern in Design Patterns, and then for the rest of the chapter they described the more verbose hoops that folks using those "other" languages were forced to jump through. Hooray for Python! :)

One last thing Alex mentioned was his strong dislike of Singletons in Python or in any language. He recommended the use of Monostates instead, where you have as many instances as you want, but force them all to share the same state under the hood. He warned that Guido hadn't liked the idea, but said that he hoped to convince him. The implementation of Monostate went by too quickly during the talk, but the slides should be posted somewhere on the PyCon website. Alex also said that it was in the new edition of the Python Cookbook, which was incidentally released today.


Object-Oriented Design with Python
Bruce Eckel

Bruce started by covering the very basics of Python's OO capability (classes, instances, methods, static methods). He then made a couple of interesting points:
  • In his opinion, problems with multiple inheritance and operator overloading in C++ weren't due to these features being "bad" -- they were due to the great difficulty in getting these features right in C++. In these cases, C++'s constraint of backwards compatibility with C had given it a serious case of warts.
  • Bruce used to think that interfaces were just for static type checking, and so therefore of course Python didn't need them. He's recently come around to the idea that interfaces are a way to find out more about a type before you call a method. They're "a way to communicate about the design." To be honest, my initial reaction was: "duh." :) But I think he was actually making a deeper point that I didn't quite get as he was running short on time.
  • One final idea: he thinks that adapters might be valuable as first-class language constructs. As he points out, we can obviously get by without this (you can roll your own adaptor in a lot of ways), but "it might help."


Traits - The Next Generation
David Morrill

David's talk turned out to be great, but as I mentioned to him afterwards, he should probably flip it around. It started with a description of these Trait things I'd never heard of, which made them sound like nice __setattr__ and __init__ hacks. But by the end of the talk, he was doing some really impressive GUI building and GUI-based attribute setting. If I understood correctly, he was basically showing us a dirt-simple way to express a strongly-typed data model as Python class definitions, and instantly have corresponding GUI and programmatic tools for dealing with that model. You get undo/redo and Python code generation for free. Traits is one of the Enthought Python tools.

One drawback: Enthought seemed a bit hesitant to publicize/release the thing. It is open source, but they're having build problems, etc. that make them antsy. It occurs to me that this is probably a pretty common chicken-and-egg problem in the open source world:
  • Enthought worries that if they release before fixing all their problems, they'll be swamped with support requests that they don't have the manpower to handle, and/or a bad reputation for releasing something that's got bugs...
  • ...but there were plenty of enthusiastic people at David's talk today that would be excited to pitch in and help fix these bugs...
  • ...but enthusiastic people like that will never find out about your project in the first place unless you release and publicize it. :(
At any rate, the package looked very impressive, and I'm sure that Enthought will get some much-deserved credit when they do release.

and The Guido said, "One Day Done"

The first day has passed. We're moving from a bunch of cool talks to another set of cool talks. With this little break called "sun missing."

Unfortunately, I had to miss the last half of the day. Saw the cool webapp talks (mentioned before), but then needed to skip out. Met up with Will for dinner and discussion, then joined by DiBona. I'm gonna smack Jeremy when I see him for his lack of cell phonage.

Tomorrow is looking shiny. Better weather. PSF Members Meeting. And a set of smoochin' talks. The database track in the afternoon looks very good. Tho I'm thinking that I gotta see my buddy Ted Leung's talk about Chandler.

2005-03-23

Sprint status reports

The sprinters gave brief reports on their work at a session just before lunch today. This session was a last minute addition to the schedule, and I arrived most of the way through Ted Leung's talk on the Chandler sprint. I mentioned the distutils sprint in a previous post.

What is a sprint?
A sprint is a focused development session, in which developers pair in a room and focus on building a particular subsystem. A sprint is organized with a coach leading the session. The coach sets the agenda, tracks activities, and keeps the development moving. The developers work in pairs using XP's pair programming approach.
Barry Warsaw talked about the Mailman 3 sprint. He recommends SQLObject as an object-relational mapping that allows you to write your classes in idiomatic Python. SQLObject generates SQL code automatically.

There were several Zope-related sprints. Jim Fulton reported on some ZODB and Zope work. Tim Peters and Christian Theune added blob support to ZODB and ZEO. Zope had problems handling large files (like multi-MB source code distributions) -- performance and memory consumption were big problems. The blob support basically puts large object on the local filesystem and integrates regular file modifications with the transaction machinery. Christian also did some basic code maintenance on ZODB.

Garrett Smith and Babu (? didn't catch his last name) made some great improvements to the pluggable authentication mechanism in Zope3.

Michael Bernstein and Andy Dustman spent several days writing a weblog application for Zope3. There are basic blog posts and Atom feeds. It took a long time because they used the Dublic Core metadata in the add and update mechanism for post. It was hard to get the schema working correctly. It was hard to get into adapters and interfaces. The resulting code ended up being small, but they had to delete a lot of code. "Zope 3 is a lot easier to read than it is to write."

Mike McLay reported on a sprint involving students from three different Arlington county high schools. (Two different schools use Python as a teaching language.) They worked on a school tool
application; they did more design than writing code. They are updating an old-style Zope application to use page templates and an external backend database. They learned about SQLObject at the sprint, from the Mailman group, and started using it.

Brett Cannon, author of the python-dev summaries for the last two years, worked on the AST branch for a few days. The big goal of the sprint was to document the design for the Python compiler. I started the AST branch a couple of years ago, but never wrote a proper design
doc. John Ehrseman is working on decorators, and Nick Coghlan is working (from his home) on generator expressions. It sounds like the work to upgrade the branch to Python 2.4 is nearly complete. What's left is the rather tedious work of testing and verifying that error handling is correct. It looks like the basic design document is in good shape, though.

I didn't catch the details of the PyPy sprint, except that they got the pickle tests running and uncovered some problems with the implementation of new-style classes. New-style classes are largely undocumented, so this isn't much of a surprise. The pickle support is deeply integrated with new-style classes, because pickle needs to create and initialize objects (including immutable objects) and introspects on them to discover the object state. Several people of the PyPy project have observed that their implementation of new-style classes is sufficiently high level that it could be the good starting point for a specification; it's easier to read the intent of the Python code than it is of the C code.

PyWebOff

This was an interesting talk by Michelle Levesque. She wanted to write a Python webapp and went to get one for her project. Surely, there is one available.

Actually... there isn't one. Kinda too bad. There are about 40 instead. Then she faced the dilemma of "which to choose?" And that's when she started the "web-off". Have a big comparison among some of the big players to see what works best.

The talk briefly described four of the seven approaches that she is looking at. She has more details on the results so far, along with a blog of results as she goes.

Very interesting talk. Personally, I don't use any of those as they generally mix the HTML output and the Python code too much.

Matplotlib

The only early afternoon talk that made a strong impression on me was John Hunter's showcase of matplotlib. I'd heard of the package, and I'd seen some of its basic output. But John showed some really neat interactive features using IPython and pylab (part of matplotlib) that got me very excited about the prospect of using matplotlib for data exploration in the way that I currently muddle through with R.

A matplotlib graph supports interactive zooming, panning, and zoom-on-region via clicking and dragging. It also provides the basic features you'd expect (logarithmic axes of arbitrary bases, lots of eye candy if you want to take the time, etc.). Something worth checking out when I get home.

Detailed notes on PyCon sessions

Ted Leung is hosting a set of detailed notes on PyCon presentations. Lots of attendees are contributing to these notes using SubEthaEdit. It will probably generate a lot more detail than a few Googlers.

Short talks from the morning

I went to three talks in the morning session, which were loosely centered around the theme of testing and extreme programming:

Extreme Programming with Python in the Classroom
Michael Weigend

Michael's students in Germany used Python to create an English text editor for grade school students and a chat room program. They used XP concepts like user stories, big visible charts, test-driven development, and small iterations. One interesting bit of teaching methodology: Michael taught his students simple GUI programming techniques by just giving them pieces of working source code and letting them explore. I thought this was great, because it mirrors the way most kids learn to use computers in general (start using this thing, and see what happens). GUI code is especially well-suited to this, due to the visual feedback, and Python sweetens the deal, since the visual feedback is so immediate.


py.test and the py lib
Holger Krekel

PyTest was started because the unittest module was "unpleasant" to extend. It's currently used in the PyPy project, among others. Holger made a couple of main points about PyTest:
  • PyTest itself is external to your code. The metaphor is that it is running against your code. So unlike unittest, you're not responsible for invoking the test code within your test.
  • There are some neat features like test generators, which are generator functions that generate more tests. PyTest then runs all of these generated tests.
  • He emphasized the user-friendly stack traces in PyTest, which did look nice.
  • Finally, he spoke a bit about other parts of py.lib, including py.execnet, which allows you to send snippets of Python code elsewhere via SSH, popen, etc. to execute remotely.
The talk on PyTest was pretty good, but since I'm already a bit familiar with the unittest module, I would have liked it if Holger had taken a bit more time to distinguish PyTest from unittest.


Agile Testing with Python Test Frameworks
Grig Gheorghiu

This was a grab-bag talk that gave us a quick look at a lot of Python testing frameworks, most of which looked pretty neat, and many of which I'd never heard of before. I'll try to come back and turn these into hyperlinks. For now, here are there names, and short descriptions of the cooler ones he demoed:
  • PyLint
  • coverage
  • buildbot
  • PyUnitPerf, which adds time and load constraints to unit testing.
  • FitNesse, which allows the user to specify test inputs and expected outputs via simple HTML tables (even generated via a wiki, as they were in his example).
  • Selenium, which is a Javascript-based tool that uses your real web browser to execute scripted tests on the web. (Seemed kind of like Greasemonkey, but for testing). You can watch your browser zip through the test, step quickly or slowly, etc. It was very impressive to see.
  • Mentioned that Jython is enjoying a lot of popularity for testing Java code (all the advantages of Python for testing, but the main body of your code stays in Java).
  • Recommended avoiding an "automation cathedral." You should have exactly the amount of daily test automation that your current needs dictate.
  • Finally, pointed us to his blog on agile testing.

Python's answer to CPAN

Python's package index now supports uploads. Richard Jones reported on the new feature during the sprint summary session just before lunch. The first package I've found that has been uploaded to python.org is Roundup. You can use the new distutils upload command or use the web interface to upload files for an existing package. There are more details about the upload feature in Richard's blog and in the other links above.

Uploads are probably the more impressive result to come out of the PyCon sprints in the last three years. The four days before PyCon were devoted to sprints. I arrived on Tuesday afternoon and found two rooms packed with people writing code -- at least 50 people. PyCon provides space and network connectivity for people to meet and work on programming projects.

I wonder how the new package database is going to support mirrors. I also don't know if it supports package dependencies.

The sprint reports session has several short talks. I'll write more later about the sprints on Mailman 3 and Zope. I'm sitting in Facundo Batista's session on the decimal arithmetic library now, and I'd like to pay more attention.

Another take on the IronPython keynote

My full braindump on the IronPython keynote looks very similar to Jeremy's, so I'll just highlight the points that stuck out to me as a first-time PyCon attendee and relative Python newbie:

  • The Peedy demo where he interactively called other .NET components to control an animated character from the Python interpreter was silly but impressive.
  • He made the whole IronPython concept seem incredibly sensible with one rhetorical question:
    Why not leverage 100s of man-years of VM development?
  • IronPython is markedly faster on PyStone than CPython.
  • Calling C# code from Python and vice-versa seemed as easy as you could hope it to be.
  • It was very impressive to see the multi-language debugger seamlessly expose an exception stack trace that started in C# and crossed over into Python. Such a debugging environment is way, way better than the world of CPython + SWIG + gdb.

IronPython Keynote

Be sure to read Jeremy's notes, they're a little meatier:

Jim Hugunin of Microsoft spoke on IronPyton (python compiling to the .net clr). Originally shown one year ago at PyCon and polished for OSCON 2004 (released under the CPL) Jim had disappeared into Redmond for a while, settled into work for a bit, then after a bit of time, released 0.6, now under their shared source initiative. . Depends on .net 2.0, which is unfortunate, as 2.0 is under-deployed and somewhat alpha.

Showed a short demo which exposed the immediacy of the python console, which is a pretty neat thing to demo with, and considering the !Immediacy of Visual Studio, this was a nice technology for people to have on Windows.

Showed python invoking xaml layouts, which was very nice. Some numbers:

About 70% faster than 2.2/2.3 cpython on xp. 2.0 framework version 80% faster than cpython (running 2.4).

Showed python calling c# and c# calling python methods. Very cool stuff. The software is .7, so it's still super-alpha, but if I had to serve python on XP I'd certainly consider IronPython, maybe even over cpython. Neat stuff. I asked about Mono and Rotor (two alternative implementations of the CLI/R) and he noted that it runs on both, but they aren't as fast. This was expected. He noted that the Mono CLR had similar performance as Cpython when running the pystone benchmark.

Short talks

The talks are scheduled for 30 minute sessions, but the speakers have to save five minutes at the end for room changing. If you throw in Q&A, then your talk might be just 20 minutes or less. That's like 10 slides (unless you're Stas Bekman, of course).

This isn't necessarily bad. Look at the fun and info that you can get out of lightning talks. Sometimes long talks aren't the best: you can end up with filler.

Whatever... I'm looking forward to the early afternoon talks covering webapps in Python.

IronPython keynote

The news from this morning's keynote is: IronPython released (at last). The running joke in Jim Hugunin's talk was pretending that it had only been two months since he joined Microsoft. In fact, it took about eight months to work out how to do an open source release once he got to Microsoft.

The new plan is to release every two weeks until there is a 1.0 release. There are one-and-a-half engineers working on IronPython. Jim is spending half his time evangelizing dynamic languages and Python within Microsoft. The hope is that the next version of CLR will have better support for dynamic languages (although it's not at all clear to me what that means).

The talk was basically the same as the talk he gave at Lightweight Languages in December, but stretched out to an hour. There was time for more demos and more technical detail.

Jim claims two advantages for Python running on .NET: It provides easy access to .NET libraries, and it leverages a substantial engineering effort on the .NET VM. He showed his standard demo using msagent. The demo crashed: "Look at this beautiful stack trace." He has used this demo to introduce people to Python, like C# programmers. The interactive interpreter has left the biggest impression on people.

On the other hand, he has seen C# programmers write this as their first Python program:
 from System import *

class C:
@staticmethod
def Main():
Console.Out.Writeln("Hello, World!")

He also had a demo of an Avalon GUI in Python. The basic demo was
trivial -- window, title, button. Jim was droll: "Doesn't that make you drool?
Don't you want to lick my screen?" He showed a xaml-generated GUI and
wrote some code to walk over the GUI objects -- basic introspection
and modification of individual widgets.

By relying on the .NET VM allows the IronPython implementation to stay
simple. IP 0.7 is about 80% faster than Python 2.4. The IP
implementation doesn't make any particular effort at optimization. It
has a straightforward code generator. From the bytecode, it looks
very much like Jython: use static fields in generator code for
constants, call into runtime implemented in C# for most real
operations -- "==" op calls "IronPython...Ops::Equal".

Guido asked: The generated x86 is somewhat larger than the Python bytecode.
Does the increased size cause worse cache performance? more misses
when you run the larger code?

Jim's answer: Based on experimental evidence, this isn't a problem. Memory
pressure is an issue in general, but he doesn't have any evidence that code size is the problem. The current IP implementation uses a lot more memory than CPython.

The next demo was loading a C# assembly into IP and calling a static method. The audience asked him to call a Python function from C#. He was entertainingly nervous about getting this part of the demo to work. He got a big round of applause when the demo worked. He passed a Python function into C# and had it called.

Next showed the debugger integration. The debugger shows a mix of IP implementation code and Python code. You can introspect on values in either language. The profiler works the same way, he said.

The standard for long-term compatibility is Jython. IP ought to run the same set of regression tests as Jython.

Some of the hard integration problems:
  • Can all strings by unicode? (Guido: Fine with me.)
  • What is the right locking policy? There's no GIL in IP, so what kind of concurrency should the builtin types allow.
  • Can we experiment with optional static types?
  • How to expose CLR-style methods on both Python types and on existing CLR types? For example, should a CLR ArrayList have an append() method like Python?
I asked Jim about the key differences between IronPython and Jython. The basic architecture of the two systems is the same, and his original IP talk looks at lot like his original JPython talk. I was standing at the microphone, so I didn't write down all the things he mentioned. There are a lot of differences that result from having C# instead of Java as the implementation language: Delegates (C#'s typed function pointers) make it easier to call between Python and C#. The generics support in the VM allows him to introspect on generic types and provide straightforward mappings to Python types; in Java, there is no way to recover the original generic types at runtime. Can't recall what else he said; I'll have to ask again.

And it begins...

It's the wee hours of the morning. PyCon 2005 begins in a mere eight hours. Or maybe seven if you're scary aggressive.

Sprints have been happening the the past few days, apparently. I wanted to arrive soon enough to participate, but the timing just didn't work out for me :-( But the rabble is gathering nonetheless. I'm here with my co-Googlers: Jeremy, Chris, and Will. After arriving tonite, I hooked up with Chris and Will for some cheap, but excellent, mediterranean food. Stupid thing is that Jeremy and Guido called us to meet up about 3 minutes after we left. Grr. Tommorow night!

The sessions are looking excellent. I need to start figuring out my winding path thru them over the next few days. Find the cool. Find the geeky. Figure out how to nap in the afternoon if I'm gonna wake for those dang keynotes! (oh wait, I'm giving one on Friday... d'oh!)

In any case... this is just the beginning. I'm hoping that we can use this space to track all of the great stuff that is going to happen this week. I'm looking forward to it a great deal. I've known some of these folks for nearly ten years. It's never a bad thing to get a chance to see, chat, and hang with them again.