OSCON 2007, Day 4

PROGRAMMING, PYTHON, OPEN SOURCE

Keynote speakers

Ben Fry talked about Processing (I missed this part, but fellow attendees who hadn’t heard of the language before we very excited and impressed.)

Bill Hilf from Microsoft notes that they’re moving to some OSI-approved licenses.

Rickard Falkvinge from Sweden’s Pirate Party spoke about their attempt to reform intellectual property law. In their first election, they got only 0.63% of the vote, buy this placed them in the top 10 parties in their first election – a record for a first-year political party. I don’t think that intellectual property regulation is a broad enough base for a political party, but the fact that they’re getting so much interest is very telling. After Falkvinge noted that political contributions are not regulated in his country, one audience member ran up and handed him cash!

Steve Yegge had some serious problems with his slides (in fact, I started feeling physically queasy after 10 minutes of mad flashing from the big screens as the tech guys ran around trying to get it to work). His essential message, delivered in the usual funny, acerbic, and rambling Yegge style, was: “open source” has a branding problem.

Session: How dtrace helped Twitter

When Twitter started getting popular, they were have serious scaling problems. Luckily they were running Solaris 10, which includes dtrace.

(It’s also in OS X 10.5 and probably going into FreeBSD as well.)

dtrace provides “concise answers to arbitrary questions.”

It’s designed for production systems: safe operation, and no overhead when not in use. But also obviously very good for development.

dtrace -l shows you all the “points of instrumentation”, i.e. hooks. About 50,000 of them in the quickie example they just ran.

dtrace has its own scripting language, the extension is .d.

dtrace -n 'syscall:::entry { @[execname] = count(); }

This runs and gathers data, then when you hit ctrl-c you get a summary table.

A dtrace script can run something else; their example was a rubyfollow.d script that was passed a Ruby script (a simple “hello, world”) as an argument.

There seems to have been some work on a dtrace-enabled Python, but as far as I can tell it’s Solaris-only.

Session: Justin Gallardo, How to Write A Killer Sugar Activity

The word “activity” more or less means “Application”. “Sugar” is the user environment for the OLPC project. All Sugar apps/activities are written in Python and GTK+, except for eToys (which is written in Squeak).

Justin got involved with the project by finishing the port of Abiword, now he manages the media player.

The HIG (human interface guidelines, remember those?) for the Sugar project are very different from those that most people are familiar with.

They’re using git for version control.

Installing is hard and slow, he’s making no bones about that. The build is called “sugar-jhbuild” if you’re Googling.

Looks like the easiest way is to install qemu and download an image (100MB to 300MB). It will run a bit slower than a native build but likely faster than the XO (the OLPC machine). Honestly, this looks like the only reasonable way to do it unless you’re interested in working on the build/install process itself.

The OLPC has a Tetris Clone called “Block Party” that was written by the same guy who wrote the original Tetris!

Alt-= gets you into the developer console.

Any time you print from a Python program, and any time you have an exception, it shows up in the log – one log per application.

Activities (applications) in the background are throttled to about 5% CPU.

All icons are SVG.

Developer tips

  • Focus on building full-screen activities. No pop-up windows.

  • Localization is key – use icons rather than words. This helps everybody – including the translators!

  • Make your stuff work both in color and black-and-white – the screen is dual mode.

  • Don’t store state or preferences inside of the activity bundle – use the SUGAR_PROFILE environment variable to store preferences.

  • Use relative paths

There are special GTK widgets for Sugar.

Online resources:

Session: Open Source RIAs

JavaFX Script: I really have a hard time getting past the awful, awful name. It used to be called “F3” – which, though opaque, is really a better name.

Apparently it uses a declarative syntax in places.

Adobe Flex: a beta word processor called “buzzword” is using Flex 2. <getbuzzword.com>. AIR will not be open source. Uses WebKit and SQLite, though.

(I had to leave this session right after the Q&A segment began, in order to make it to Guido van Rossum’s Python 3000 talk. The first questioners dove right into the license restrictions on the Flash player though!)

Session: Guido van Rossum, Python 3000

(If you’ve seen or heard Guido talk about Py3K in the past year this is going to be very familiar. I wonder if he would consider creating a “just the diffs” version of the talk.)

Update: Guido has posted a short Python 3000 FAQ on artima.com. And a second one.

Current timeline:

  • 3.0 alpha 1: August 2007
  • 2.6 alpha 1: December 2007
  • 2.6 final: June 2008
  • 3.0 final: August 2008

He makes a good point that without full unit test coverage you’re not going to exercise your code enough to get the Py3K warnings, which you need to see in order to know what to fix.

  1. start with unit tests, full coverage
  2. port to 2.6
  3. test with py3K warnings mode on
  4. fix all warnings
  5. use 2to3 utility to convert to 3.0 (no hand-editing of output allowed!)
  6. test converted source code under 3.0 (of course you have ported your test suite)
  7. fix stuff in 2.6 source and goto “test with py3k warnings” step
  8. release separate 2.6 and 3.0 versions

Tips

  • use the sorted() built-in rather than sort method
  • use xrange(), not range() (though remember that range() will act like xrange() in 3.0)
  • use // for int division
  • use relative imports
  • use the new exception hierarchy
  • segregate your unicode processing
  • don’t go from 2.5 or earlier to 3.0
  • don’t try to write code that works both in 2.x and 3.0

Unicode: Default source encoding is UTF-8; unicode letters are allowed in identifiers; some issues remain (e.g. normalization); stdlib remains ASCII.

An abstract base class in Py3K is defined as a class with at least one abstract method. There’s an @abstractmethod decorator. There will be “voluntary” base classes for standard APIs: Iterable, Iterator, MutableMapping, Real, RawIOBase, Hashable, Sized, Container, etc.

Continuing the move toward iterators and lazy evaluation: zip(), map(), and filter() will all return iterators. As will dict.keys(), .items(), and .values() – these three will return something new called a “dict view”, which are iterables (but not iterators).

New super() call: When called without args, it figures out the current class and self. This is the way I’ve always wanted it to work!

Set literals: {1, 2, 3} – this is very nice. (An empty {} will still produce an empty dict. Fair enough.)

Set comprehensions and dict comprehensions. Also very nice.

lambda lives – reduce dies.

John Levon commented on Tue Jul 31 06:37:34 2007:

There’s nothing Solaris-specific in the DTrace Python support. In theory, any OS with DTrace ported will be able to use the new support I added.

Paul commented on Fri Aug 3 02:03:51 2007:

That’s good to hear, John, thanks for taking the time to comment.

Bring on OS X 10.5!

Share: