[Moving a discussion about capabilities to where it arguably belongs] [Ben Laurie]
The point about capabilities is that mere possession of a capability is all that is required to exercise it. If you start adding security checkers to them, then you don't have capabilities anymore. But the point is somewhat deeper that than - given capabilities, you can implement proxies without requiring any more infrastructure - you can also implement security schemes that don't really correspond to any kind of security checking at all (ok, you can probably find some convoluted way to achieve the same effect, but I'll bet it comes down to having tokens that correspond to proxies, and security checkers that allow you to proceed if you have the appropriate token - in other words, capabilities, but very hard to use).
So, it seems to me, its simpler and more powerful to start with capabilities and build proxies on top of them (or whatever alternate scheme you want to build).
Once more, my apologies for not just getting straight to the point.
BTW, if you would like to explain why you don't think bound methods are the way to go on python-dev, I'd love to hear it.
It seems to e a matter of convenience. Often objects have many methods to which you want to provide access as a group. E.g. I might have a service configuration registry object. The object behaves roughly like a dictionary. A certain user may be given read-only access to the registry. Using capabilities, I would have to hand her a bunch of capabilities for various methods: __getitem__, has_key, get, keys, items, values, and many more. Using proxies I can simply give her a read-only proxy for the object. So proxies are more powerful. Before you start saying that we should use capabilities as the more fundamental mechanism and build proxies on top of that: as you point out, we already have an equivalent more fundamental mechanism, bound methods, which is equivalent to capabilities. It's just that raw capabilities aren't very usable, so one way or another we've got to build something on top of that. --Guido van Rossum (home page: http://www.python.org/~guido/)