GeezerVison

Fred Drake wrote:
> On May 21, 2008, at 5:41 AM, Nick Coghlan wrote:
>> While a proxy class written in C would no doubt be faster than one 
>> written in Python, one of the things I'm hoping to achieve is for the 
>> stdlib generic proxy to serve as an example for people writing their 
>> own new-style proxy classes in addition to being usable as a base 
>> class (Adam Olsen suggested ProxyMixin instead of ProxyBase as a 
>> possible name).
> 
> 
> The idea that it would serve as an example seems odd; the reason to make 
> things part of the standard library is because their implementation 
> needs to track the Python core closely.  For a proxy, it would be the 
> need to reflect additional slot methods as they're added.

It does that too - the unit tests I just added to the tracker issue for 
this proposal will actually start to fail if something is added to the 
operator module without the unit tests for the proposed ProxyMixin being 
updated appropriately (it would actually probably be a good thing to 
have something similar in the weakref.proxy test suite to prevent a 
repeat of our effort with forgetting to update that when the 
operator.index slot was added)

>  A Python 
> implementation may be able to do this just fine, but the performance 
> penalty would make it uninteresting for many large applications.

It should still be faster than the classic class __getattr__ based proxy 
implementations it is primarily intended to replace. People that are 
already using a C-based implementation like zope.proxy aren't going to 
be affected by the removal of classic classes in 3.0, since they weren't 
relying on them anyway.

In many ways, the TestProxyMixin test suite may prove more useful in the 
long run than the ProxyMixin class itself, since the test suite provides 
a template for how to test that a proxy class is doing its job, and also 
to automatically detect when new C-level operations have been added to 
the interpreter that the proxy class doesn't support.

> For what it's worth, zope.proxy does support subclassing.

But not in a mixin style - since zope.proxy is an extension class in its 
own right, it can't be combined with other extension classes.

The Python version can be combined with anything.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org