Patch to backport dictviews to trunk. Consists of some trickery:

 - new 'viewkeys', 'viewvalues' and 'viewitems' methods of dicts,
returning exactly what 'keys', 'values' and 'items' return in 3.0: three
new types defined in dictobject.c
 - a future import (dictviews) that changes which opcodes are generated
for (some) attribute access
 - special opcodes for getting and setting 'keys', 'values' and 'items'
attributes from an object. These opcodes do nothing special unless a
future import is in effect in the calling code block *and* the type they
are called on is a dict subclass, in which case they translate 'keys',
'values' and 'items' to 'viewkeys', 'viewvalues' and 'viewitems'.
 - similar specialcasing in getattr() and setattr()

After talking to Guido, got rid of the future import magic in favour of
just providing 'viewkeys', 'viewitems' and 'viewvalues' methods of
dicts. This makes efficient 2.6-and-3.0 dict-using code possibly by
making 2to3 translate the view-methods directly to keys/values/items in
3.0, and not wrapping everything in list().

I'm going to defer this to 2.7.

I have refreshed Thomas's patch to reflect recent updates to dictviews.
I also added the documentation for dictviews.

Here is a patch for 2to3 to support the translation of code using dictviews.

Can someone review the patches? I would like to commit this later this week.

The patch (backport_dictviews.diff) doesn't seem to work for me. I
applied it on trunk after a svn up, did "./configure && make" and when I
tried d.view{items|keys|values} Python segfaulted:

Python 2.7a1+ (trunk:76759M, Dec 12 2009, 00:28:52)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> d = dict(a=3, b=5)
>>> d.viewitems()
Segmentation fault

I'm tested it on Ubuntu 9.10.

The docstrings of the three methods are also wrong:

+PyDoc_STRVAR(viewkeys__doc__,
+	     "D.keys() -> a set-like object providing a view on D's keys");

This should be "D.viewkeys() -> ...", same with the other two.

It looks like that crash is caused by some bug in the implementation of
PyUnicode_FromFormat(). I rewrote my patch to avoid it and added some
additional unit tests.

The tests were missing in my last patch. So, here's a new one.

Committed in r77428. Thanks for your comments!