Damn Those AdWords!

OK, this is a guilt trip. You have been warned.

One of the things about being an AdWords user is that you realize the cost of a click-through.

So just now, trying to find out exactly how far the proposed $102,000,000,000 (that's an obscene waste of taxpayer dollars) spend on the Iraq war would go towards making sure everyone in the world had potable water to drink, I clicked on a sponsored link. As soon as the page came up I realized that I had just cost these people money.

So, I could have sent them a couple of bucks to salve my conscience. Instead I decided I would give them something scarcer, so I am taking a few minutes of my time to ask you to visit their Web site, and understand (or at least struggle to understand) why one sixth of the world's population is unable to take clean drinking water for granted, and think about what that must be like for them. I figure that if only ten of you click the link then I have probably contributed the equivalent of at least $10. If you bother to post a comment here saying you have clicked, I will also send PlayPumps $6 per person, thereby providing someone with clean water for ten years—I doubt I have so many readers, but prudence cautions me to limit the total to $480.

Then go to my other blog and look at the mounting cost of the Iraqi suppression at the top right hand corner. If the USA spent one-tenth as much providing drinking water to the world as it does spilling blood it would be hailed as a benefactor, and welcomed throughout international society. Wouldn't it be nice to have a few other countries on our side for a change? How about a "coalition of the grateful"?

How come lame duck presidents never seem to grapple with this as they piss away their few remaining months in power? God forbid it should get in the way of the plans for yet another self-congratulatory presidential library. Don't they realize these kids will be programming in Python once they get their OLPCs?

[Final update, April 7: Not as ruinous as feared, but I have
just send PlayPumps a check for $120. Thanks for participating! Steve]

Ye Olde Blog Spam

For the past two days now both Planet Python and Unofficial Planet Python appear to have been receiving about four copies a day of a blog, amusingly (for someone so apparently clueless) entitled Ye Olde Clue.

Could someone please hit the author with ye olde clue sticke and stop this nonsense? We are all used to seeing occasional glitches, but this blog just seems to go over the top.

Goodbye, Arthur C. Clarke

Since my blog is emblazoned with a quotation from the man it would be ungracious of me to let his death last week pass by without some remark. A man of formidable vision, Clarke envisaged the geosynchronous satellite years before anyone else, but was denied a patent because his disclosure of the idea in a Wireless World article was regarded as prior art. (How ridiculous this makes the US Patent Office's current lax diligence in the software field).

He was an inventive science fiction author, and one whose books would frequently withstand the test of a second and subsequent reading. Many were more prolific in volume, but few could challenge him on the scope of his ideas. In later life his move to Sri Lanka kept him in touch with the needs of the people increasingly crammed together on this small shared ball of rock.

Who knows where he ranges now. The world is a smaller place for his passing.

Image: Arthur C. Clarke Foundation

Packaging Python

There's an extensive discussion at the moment on the python-dev list about how python modules and applications should be packaged up in future. This all relates to the distutils and setuptools features, which are great when they work and horrible when they don't. There seems to be general agreement that an uninstall feature would be useful.

My own point of view is that there are different requirements for installing applications for end users and modules for developers. In the former case I believe it would nowadays be easiest and least error-prone if each (Python) application were installed with its own interpreter and all dependencies. While this seems horribly wasteful, it neatly avoids any kind of version lock-in and allows application upgrades. In the latter case then something more like the traditional setup.py install is more appropriate, and the installation probably doesn't need to be recorded in whatever mechanism the system uses to record installed applications (e.g. Add/Remove Programs under Windows).

Whatever the result, it does appear that 2.6 could get us closer to a universal solution to installation problems.

Bruce Perens Needs Your Help

A co-founder of the Open Source Initiative, Bruce Perens is now concerned that the body is becoming increasingly dominated by vendor representatives who do not necessarily have the interests of the open source community at heart.

You can read about why he feels this is necessary on his campaign page. I would suggest that perhaps a change in bylaws is also required, since it appears from Article V Section 5 that the Board of the OSI is, or has the potential to become, a self-perpetuating cadre with no outside accountability. I can't help feeling that's a little unhealthy.

Please visit Bruce's Web site and support him in his campaign to keep Open Source open!

PyCon Friday: That's All, Folks

That's enough blogging, now I'm just going to try and enjoy the conference as much as I can.

PyCon Friday: Python Software Foundation News

Well, the PSF meeting is over, and we have eight new members. The Board of Directors has changed composition slightly, with the departure of Andrew Kuchling (left) and David Ascher (right).

Andrew was the first recipient of the Frank Willison Award for services to the Python community. He did amazing things for PyCon as its second chair (last year and the year before), and has put in huge amounts of unseen work on other issues but unfortunately is now too busy at work to continue as a PSF Director.

David was a founding Director, I believe, and the co-author of early editions of Learning Python and co-editor (with Alex Martelli) of the Python Cookbook. Our loss is the Mozilla Foundation's gain. His new job as head of the corporation to nurture the Thunderbird software meant that he too had to move on, but he's promised to continue to do all he can to support the Foundation even though his new role will clearly be taxing. We all wish him well.

Raymond Hettinger and James Tauber, both long-term supporters and users of Python, now join us on the Board. Raymond may be known to you as the author of the itertools module among his many other fine contributions to the Python core; without his influence Python would still lack a decimal module. James has more than ably represented the Foundation as its Summor Of Code coordinator, and is also a prolific author of code, most recently in the Django arena.

The eight new elected members are: Titus Brown, Mark Dickinson, Amaury Forgeot d'Arc, Christian Hiemes, Van Lindberg , David Mertz, John Pinner and James Tauber. Congratulations to them all. Three new sponsor members were also elected: EarnMyDegree.com, HitFlip and Sun Microsystems. We are happy to have their support.

At this evening's meeting of the newly constituted Board Stephan Deibel followed through on his announced intention to step down after four years as Chairman, though we are pleased to know he is continuing as a Director. I am the new Chairman for the next year. I hope I can do half as good a job as Stephan.

PyCon Friday: Guido's Keynote

Guido started by suggesting that this was going to be boring because it's the same talk as last year: Python 3.0 is coming, it's going to change everything, don't worry!

Matz, the author of Ruby, has said that "open source needs to move or die". Guido sees 3.0 as a chance to remove some of the sticky mistakes he made fairly early in the development of the language. Python is now 18 years old, its first open source release was in February 1991, and it's time for a change.

Guido gave a quick summary of major breakages. Most Python users by now re aware that the print statement is disappearing, that integer division is becoming a separate operator and so on. Guido was more interested in promoting the new features.

He feels that argument annotations will allow users to experiment with the feature, and that some interesting uses will eventually be available in the standard library. Abstract base classes offer an optional way to escape from duct typing. The wild-card unpacking assignment will offer more flexibility, and the new string formatting (similar to C#'s formatting feature), and many small improvements which he just displayed on one single slide.

Oberall Python 3.0 will become a smaller language, and some of the redundant older ways of doing things will be removed in the interests of keeping the language manageable and "fitting your brain". It is ready to evolve, and the new features provide the basis for that evolution. We have a good migration strategy (move to 2.6, then use warnings to make your 2.6 compatible with 2to3 automated translation).

There is no hurry - the 2.x series could be with us for another five years. In the meantime convert to new-style classes, stop using obsolete modules, and make more use of generators and iterators. Leave the small stuff to 2to3, the automated translator.

Porting C extensions may be more troublesome, because many API's will be removed.


Q (Jacob Kaplan-moss): One of Django's features is retaining compatibility with older Python versions, so a full port to 2.6 would effectively break backwards compatibility; what should our migration strategy be?

A: Migrate to 2.6 but don't immediately convert it for migration; track your user base and convert to 3.0-compatible source when it's practical without causing too many problems to your user base.

Q; 2to3 could be useful for frameworks that need to inport other people's code; will it be available with 3.0?

A: It would need some restructuring of the code, but is doesn't sound unreasonable; bring it up on the Python 3000 list, and offer to do a little of the work!

Q: Will the ABCs include an abstract sequence base class?

A: There's a container class, but not something explicit for sequences.

Q: What will the performance differences eventually be between 2.X and 3.0?

A: in the long term I don't anticipate much difference, though 3.0 may take a small hit initially.

Q: You said there would be no change to the whitespace issue - why not?

A: Most of the people here wouldn't let me! But the language is going to be stricter about the potentially damaging uses of mixed tabs and sapces.

Q: Is localization going to start working its way into the way we process strings?

A: I'll have to defer to others on that one; but there won't any longer be a need to work with data in specific encodings.

Q: I was expecting to be able to import 2.6 modules directly into 3.0 as opaque objects, avoiding the need to port legacy code; why can't this be done?

A: A virtual machine that's capable of running both 2.x and 3.0 bytecodes would be a great thing to have, but incompatibilities in the way the basic types operates make this not just ill-advised but impossible.

Q: Is there any change to the GIL strategy for 3.0? Our large applications with Python embedded need to take advantage of multiple CPUs.

A: For better of for worse, it's not going away, and there are good reasons for this, which have started to convince even the most reluctant. The pyprocessing module can help, or look at Jython or IronPython.

Marketing Open Source

Here's an interesting idea. Maybe the PSF should try to fund the development of a stick with Portable Python or Movable Python and a bunch of applications on it? That would have been amazingly useful for the PyCon tutorials this year.

PyCon Friday: the Calm Before the Storm

Late to bed last night, and clearly too sleepy to set the alarm properly, so woke up today feeling a little groggy rather later than I had intended. Laptop behaving so far, fingers crossed.

Breakfast and the keynotes first. For the morning session the only two talks I want to hear clash with each other! PSF members' meeting at lunchtime, then chairing a session in the afternoon (a good way to make sure you get to hear some talks you want to). Trying to leave the evening open for "social business" activities.

I'm asking all the newcomers I meet what made them come to PyCon this year in an attempt to understand the explosive growth. It seems that a lot more people are starting to use Python now, vindicating my ten-year master plan to be involved with a significant technology by the end of this decade. Wonder whether it will do me any good.

Alex Martelli says I should consider writing another book, and wants me to contact a publisher. Whenever anyone says this I always remember the $2.50 royalty check I got once for Python Web Programming, and this brings me back to reality. I told him I might consider it if he'd be my technical editor again. His encyclopedic programming knowledge was terrifically useful last time.

Talking to Glyph Lefkowitz in the bar about books, he asked me how sales were going and I told him it is still in print but I am waiting for it to be remaindered (though it's hardly Books-a-Million material). He was nice enough to say that compared with other six-year-old books on web technologies there was still a lot that was relevant, which is definitely a complement. I did try hard to include explanations of the fundamentals, and I guess that counts for something.

Enough, I'm getting hungry.

Practical Applications of Agile (Web) Testing Tools

This was a practical tutorial by Titus Brown and Grig Georghiu, two accomplished presenters who have given popular presentations at the last two PyCons. Titus opened the presentation, and told us he wanted us to be "test infected" - to make testing a necessary part of our development process. He confessed he feels a sense of physical discomfort when he writes untested code.

He gave us a number of practical guidelines, the most interesting of which were: start small; focus on actual problems; use continuous integration. The goal of testing should be to fail as quickly and as hard as possible: failure is good, because it reveals a need for revision. You should plan for testability, and as your experience level increases you will find that you naturally tend to do this.

Use a hierarchy of tests. The initial tests should run in under 20 seconds; only if those tests pass should you run the full test, which will take longer; then run regression tests, and then (if you have defined them) the acceptance tests. The point is that much of this work isn't done on your time: your continuous integration may be an overnight run, but you don't have to stay while they run. Titus feels that any test that takes over a couple of hours has limited (though definitely not zero) value, due to the lack of immediacy in the feedback it provides.

Taxonomy of testing: unit tests, functional tests, regression tests, UI tests, acceptance tests, integration tests, continuous integration, performance tests. Do you even know what all these are? Which to you need to define and use?

The more complicated it is to run the right tests, the higher the probability they won't get run. Titus talks about different strategies: TDD (Test-Driven Development) and SDT (Stupidity Driven Testing) , which he equated with TED (Test Enhanced Development). The general myth is that you are a bad person if you don't use TDD, but SDT is very important because you can ensure that bugs get properly squashed by adding specific tests after discovering one of the gruesome faults we all put in ur software from time to time.

Tests can be used to constrain your code; they force you to document your expectations, both internally and externally. internally, use more assert statements. Externally, write unit, functional and regression tests as "black box" tests to verify external behavior.

A "test umbrella" removes the need for memory. Everything should report back to a single source. This gives you a way to tell a new developer "run this; if it doesn't work, you have something to fix". You just have to remember to run the tests, not go through some complex sequence of commands that need separate documentation. This automation investment will reap big dividends in both time and quality.

Testing really helps when you want to refactor.

While code coverage may not be a good metric, it's definitely the case that if you don't run every line of code at least once in your tests then the possibility of failure becomes much higher. Line coverage is necessary, but not sufficient. Continuous integration helps you discover less obvious errors, like changes in process you forgot to document.

WSGI intercept is a useful test mechanism because it monkey-patches the Python web libraries.

[Interesting demos; I went for water for the speakers just before they started; my tests failed, and I never discovered whether they were supposed to or whether I had missed some crucial step while I was out].

The scotch tool is a recording proxy that will record everything that passes between the browser and the server: exceptionally useful for capturing AJAX interactions. It can also replay recorded sessions, and ensure that the responses that come back are "the same" (with minor exceptions such as ignoring date changes).

Figleaf is a code coverage recording tool. It saves it results in a pickle-based format, and can perform intelligent comparisons between tests, taking the union and intersection so you can easily discern what still needs testing.

Nose is a system that allows testing with a much lighter footprint than unittest. It will also all other doctests and unittests it can find if properly encouraged to do so, and can be used to add module-level setup and teardown.

Grig then took over and first described and then demonstrated Selenium, a testing tool written in Javascript that runs inside the browser (and probably one of the best-known web testing tools). It's one of the few tools that can adequately test AJAX functionality, and it's the default testing tool at Google). It has several components.

The core is augmented by an RC (remote control) module, and IDE (a Firefox add-on), and a Grid module that seems to relate to parallelized testing.

The biggest issue in defining Selenium tests is locating the required elements in the page. It would be much easier if web authors gave all elements IDs, but in practice you often end up using xpath, which has downsides. Many times there is no other way.

The IDE component allows you to record interactions with web servers, but again you have to be careful to use repeatable event sequences (e.g. pasting is not repeatable); the IDE is probably not as easy to use as Twill, but some AJAX applications are almost pure client-side, with very few server round-trips, and Twill is useless with these as it can't intercept the traffic.

Firebug is an essential component in developing the tests, as is the XPath Checker add-on, which helps greatly in generating the element locators.

The basis of Seleniun tests is a long string of locators and assertions. Selenium RC runs as a reverse HTTP proxy, bypassing the "same origin" cross-site scripting protections that normally insist that scripted content has to come from a single domain. By fooling the browser this way remote control allows you to write test of a remote server inside the local proxy. It also allows you to build simple looping constructs. Of interest to readers will be its ability to export test cases as (rather ugly) Python code. Google has a whole team working on Selenium, and others are also working to improve it, and extend it to broader browser support.

Grig then went on to describe buildbot, a continuous integration testing tool that allows a master system to run build (or indeed any other) commands on remote slaves and aggregate reports from the clients in a simple, readily available web format.

Although some people perform continuous integration on a single platform, buildbot was designed from the start to allow the master to drive the same tests across multiple clients and thereby discover cross-platform bugs that might otherwise go undetected.

Greg ran us through a configuration file. The learning curve can be steep, but once your buildbot is configured it usually needs little maintenance. He also highlighted the fact that someone has to keep on top of buildbots and avoid bitrot by displaying the currrently parlous state of the Python buildbot farm. Many clients are down, and those that are running appear to be failing their tests.

The evening closed with a brief discussion of Fitnesse, which is a higher-level tool that has you define tests declaratively in a language that allows you to refer to the concepts of the application domain; this makes them easier for the customer to comprehend, for example. The tests are maintained in a wiki.

I was beginning to flag a bit by now, so I can't really give you an intelligent summary better than Grig's "it's a Wiki that runs things". Ideally the client will at least understand the test descriptions.

All in all an excellent and enjoyable presentation that not only gave me some great ideas for testing but also left me more determined to introduce it into my web projects.

Getting Started with Pylons/TurboGears 2: Modern Python Web Development

This presentation was as frustrating for me as it probably was for the presenters, Mark Ramm and Ben Bangert. Unfortunately the examples for the first part of the tutorial relied on having up to date copies of lots of packages, and the audience were unable to download them from the Internet as the hotel staff appeared to be having some difficulty connecting 500 geeks to the fat Internet pipe through their wireless infrastructure, and connectivity was extremely intermittent.

Things went from bad to worse when I finally managed to download the required software from the Internet and found that my examples failed: it turned out that only the presenters' machines had the necessary combination of packages. Consequently a lot of the first hour was wasted in trying to organize a thumb-drive bucket-brigade to ensure that all present had the needed stuff loaded. I can understand Mark's anxiousness to present the latest and greatest TurboGears to the audience, but I was there primarily because I wanted to get back into the technology so as to be able to make fair comparisons with Django.

While we were trying to get the load problems sorted out, mark talked about the WSGI interface and its role as a standard in the Python web world. He then talked us through a couple of practical applications, and I ended up with a simple server working based on the reference implementation, wsgiref. We then implemented the same functionality using cherrypy.wsgiserver, observing that the fundamental techniques weren't particularly different. The third exercise didn't actually add much for me, since we just had to get the existing servers to replace the initial output with a listing of the environment dictionary.

Then we moved on to TurboGears. Alas, I ended up typing in code from the handout while Mark was explaining the supporting functionality, and when all was said and done I didn't notice a lot that was new in terms of how you put a TurboGears application together. In one way this is very good, because it means that the TG re-implementation has retained the same API that its developers have become familiar with; in another it's bad, because I didn't feel I actually learned all that much as someone who had already put TG applications together, albeit small ones. Much of what was said was narrative about the state of the software rather than directed towards learning the technology. I didn't have the sample web finished, with nine pages remaining of the handout by the time Mark's part of the session was over.

Ben Bangert then proceeded to explain the differences in philosophy between TurboGears and Pylons. I'm sorry to say that my experience on the first rather-more-than-half of the tutorial left me unable to concentrate sufficiently, and I didn't absorb as much as I would have liked. I don't remember any practical work at all, and I didn't end up with a handout, but I don't know whether I missed it or what.

This was the first of a matched pair of tutorials, the second discussing advanced use of TG and Pylons. I didn't attend it because I was booked on something else in the evening session, so I hope that those who did found that this tutorial had provided them with the necessary background.

PyCon Day 0: A Mixed Bag

Wel, the curse of PyCon struck again this year, and I woke up bright and early to find that my laptop had blue screened. Three hours to the start of my tutorial presentation! Fortunately I was in good shape in terms of backup, having brought my external disk drive with me, and Greg Lindstrom was also able to provide me with a thumb drive containing the PowerPoint slides and PDFs, so I was prepared for not having my own computer available. Fortunately after ninety minutes of repair work the machine was once again in a bootable condition, but it meant that I missed breakfast and was a little later into the tutorial room than I anticipated.

It was difficult for me to judge how well the tutorial went down, so I'll have to rely on people who attended it either commenting here or writing it up in their own blogs. I hope they all remember to fill out the evaluation forms, available electronically as well as on paper. That way I'll have some sort of objective evaluation, but at least a couple of the audience were kind enough to tell me afterwards that they felt better prepared to deal with the conference, which was after all the main idea.

In the afternoon I attended Getting Started with Pylons/TurboGears2 & WSGI: Modern Python Web Development, by Mark Ramm and Ben Bangert, and in the evening Practical Applications of Agile (Web) Testing Tools by Titus Brown and Grig Georghiu. I'll be writing those up in separate posts if you're interested.

In and amongst all that, friends old and new continued to pour in. Too many to mention without fear of upsetting someone, but excellent to see. This conference is going to be a blast, I just know it, and I am very excited about the prospects of the next few days even though it means being away from home. There's a buzz. Or is it just me?

PyCon: Plus ça Change ... *

As is my habit when I am teaching, I arrived in plenty of time (midday today), thinking I would probably be able to help with something or other. Turns out only Drew Moore got here before me (arriving on Tuesday, a luxury I did not have given that I am spending two days at the sprints once PyCon is over).

By 2 pm David Goodger, the chairman, and Doug Napoleone (who has done such sterling work on the PyCon-tech software that pretty much runs the whole deal) had arrived, so we shot the breeze over a few beers and I discovered that the kiloPythonista was a reality—awesome! The organizers (among whom I am no longer counted, except possibly in an emeritus sense) have done a truly magnificent job putting this deal together, and are to be congratulated.

In any gathering of 1,000 people there will be glitches. There are already rumblings about parking (though you can park for $6 a day within a few blocks if you still have the use of your legs). Another issue is that the hotel has apparently realized (after the deal was mentioned on the web) that they might be well advised not to let people to join Priority Club and get complimentary Internet service in their rooms, given that they are trying to share two T-1s among all the hotel guests. Which is pretty ironic, given that PyCon is giving away access to a 45 Mbps pipe downstairs all week. Perhaps we should offer to let them try our bandwidth after we've gone (the minimum term was a month), and see how their customers like free access to a fat pipe. Fat chance, I suspect, since the hotel is a conventional business and not really yet in touch with the long tail.

This conference is going to be huge, in every sense of the word. I have already met several people who are attending their first PyCon, and a large number of old hands who realize that there's a lot of fun to be had just meeting up with people you haven't seen since last year and finding out what they've been up to. As I said to tummy.com's Evelyn Mitchell in the bar last night, coming to PyCon is a bit like coming home.

Some people are wondering whether this increase in size is somehow going to spoil PyCon, and make it less than it has been in the past. I don't believe we need to worry. Despite Guido's rather pedestrian view of the Python community (expressed in an interview I did with him to be published in the conference edition of Python Magazine), I believe it is special. It's special because it collectively works to be different, and welcoming to newcomers (which is essential if the community is to thrive and grow—without that, PyCon would not be the special event that it is), and outgoing, and engaging. As geek communities go, Pythonistas are actually pretty extrovert.

Anyway, it's late and I need to get my beauty sleep, but I just want to record my goals for this year's PyCon. First, I want to forge new relationships on a business and personal level, and reinforce old ones. Secondly I want to ensure that the Python community as a whole knows about Holden Web's Python classes (which are currently being rather ineptly advertised), and understands that we are open for business. Then I want to learn some great new things (including, I hope, how to use Twisted), to teach fifty newcomers the delights of Python, to scope out the PyCon-Tech software with a view to refactoring and migration to the Django trunk, and make a start on a SQL Server back end for Django. Oh, and I am also looking for ideas for more Random Hits articles for Python Magazine too.

Large ambitions, but it's a large conference this year. As Chris McAvoy, whose enthusiasm is largely responsible for bringing PyCon to Chicago, has just written in his blog, hooray for PyCon!

* "plus ça change, plus c'est la même chose" — "the more it changes, the more it's the same thing", usually translated as "the more things change, the more they stay the same" (Jean-Baptiste Aphonse Karr, Les Guêpes, January 1849)

One kiloPythonista?

With only days to go to the end of pre-conference registration the numbers for PyCon 2008 are tantalizingly close to the thousand mark (as I write, 941 registered, and the possibility of a few additions in the pending changes). It would be nice to be present at the first kiloPythonista gathering, and there is often a minor surge at the very end of the registration period. Whatever happens, this conference represents a new high-water mark in Python interest.

Since I missed out on the (apparently very entertaining) Twisted BoF last year I have attempted to make amends by setting up a session in which I try to learn Twisted in public. I'm not sure how much I will manage to learn, but I hope it will be entertaining. We might even manage to generate some useful notes for others faced with the same task.

There's been a lot of talk about the catering on the organizers' list recently, leading to no real conclusion except that you can't please everyone. I am sure nobody will starve, though, and that's the main thing.

The Chicago Python group are meeting on the Thursday evening before the conference proper starts. I wanted to join them, but I am signed up for an evening tutorial which continues until after the end of the meeting. I hope they will publicize the location of the after-meeting meeting, and maybe we can share a drink.

Plans to promote a bid for PyCon to return to DC in 2010 have been shelved, as I don't have the time to do much about them. I was skeptical of the value of using a conference organizing company, but several of those who have been involved in the planning say that the assistance has been invaluable. It looks as though there may be a Python BarCamp in DC in the fall, though, and I am now setting my sites a little further out for the next DC PyCon.

All in all I am really looking forward to this PyCon, number six in the series. Hope to see you there - please look out for me (my photo is in my Blogger profile, among other places) and introduce yourself!

PyPy Catching Up ...

An interesting post on the PyPy (Python written in Python) blog explains that PyPy has finally, on carefully selected tests, benchmarked ever so slightly faster than CPython (1% faster on one test, 11% faster on the other).

It's also interesting to note that a 20% speedup is achieved by method caching, which avoids the need to create a new bound method every time a method is referenced relative to an instance. Apparently the same technique would be usable in CPython were it not for certain C modules directly modifying the __dict__ of new-style classes. I wonder if CPython could obtain an equivalent speed-up, and if so whether it would be worthwhile making the guilty C modules restrict themselves like PyPy does.

I have high hopes that within a year we will regularly be seeing benchmarks that show PyPy outperforming CPython.

If you can't wait for that, and can live with heavy restrictions on your use of the language, try RPython (another product of the fertile PyPy project, and one in which Stackless Python's Christian Tismer had a hand) which on occasion benchmarks faster than C!

Industry Support for Python Broadens

In a move of significance to all Python users Sun Microsystems has broadened its support for dynamic languages still further. There was some interest in their announcement less than six months ago that they had hired Charles Nutter and Thomas Enebo, developers of JRuby.

Today we learn that they have recruited Frank Wierzbicki and Ted Leung. Frank has been one of the two principal maintainers of the Jython project for a good long time now, and has brought the language forward to the point where it supports the newnew-style classes, a significant milestone in compatibility with CPython. Ted is a long-time member of the Apache Software Foundation who was a member of the OSAF's Chandler team for the last four years.

Sun was a great employer for me (I was badge number 1536, I believe, starting back in 1985), and I hope that Frank and Ted enjoy working there. It's certainly a great place to meet people with exceptional intelligence, and the fact that both Sun and Microsoft are now visibly taking a serious approach to dynamic languages in general and Python in particular is terrific.

Sun and Microsoft are both sponsoring this year's PyCon, for which registrations recently topped 900. If you want to meet them there then you still have four days to register at the pre-conference prices!