[Python-Dev] Issue 643841: Including a new-style proxy base class in 2.6/3.0

[Nick Coghlan]

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.  A Python 
> implementation may be able to do this just fine, but the performance 
> penalty would make it uninteresting for many large applications.

I've added a documentation file to the tracker item and kicked it in 
Barry's direction (I also bumped the priority to 'release blocker' 
because I think we need an explicit decision on this one from Barry or 
Guido before the first beta release of 3.0).

Here's what I included in the proposed documentation for ProxyMixin 
(note that I modelled the implicit unwrapping behaviour directly on the 
behaviour of weakref.proxy):

    class:: ProxyMixin(target)

    A proxy class that ensures all special method invocations which may
    otherwise bypass the normal :method:`__getattribute__` lookup
    process are correctly delegated to the specified target object.
    Normal attribute manipulation operations are also delegated to the
    specified target object.

    All operations on a :class:`ProxyMixin` instance return an unproxied
    result. Operations involving multiple :class:`ProxyMixin` instances
    (e.g. addition) are permitted, and endeavour to return the same
    result as would be calculated if the proxy objects were not involved.

    Custom proxy class implementations may inherit from this class
    in order to automatically delegate all such special methods
    that the custom proxy class does not need to provide special
    handling for. This may not be practical for more complex
    delegation scenarios (e.g. a local interface to a remote
    object, or delegating to a weakly referenced target as in
    :code:`weakref.proxy`), but :class:`ProxyMixin` may still be used
    as a reference when developing such classes to identify which methods
    must be defined explicitly on the proxy type in order for them to be
    delegated correctly by the Python interpreter.

Cheers,
Nick.

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