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

[Michael Foord]

Nick Coghlan wrote:
> One of the tasks where classic classes are currently far superior to 
> new-style classes is in writing proxy classes like weakref.proxy - 
> cases where nearly all operations need to be delegated to some other 
> object, with only a few being handled via the proxy type object itself.
I've needed to do this a few times when wrapping libraries.

Michael Foord

>
> With classic classes, this is trivial, since __getattr__ is always 
> consulted, even for retrieval of special methods.
>
> With new-style classes, however, the __getattribute__ machinery can be 
> bypassed, meaning the only way to proxy an arbitrary instance is to 
> define all of the special methods that have C-level slots.
>
> This issue was actually first raised five and a half years ago [1], 
> but has never been a particularly pressing problem, as anyone with any 
> sense that needed to write a proxy object just used a classic class 
> instead of a new-style one. In 3.0, with the demise of classic 
> classes, that workaround goes away.
>
> So what do people think of including a ProxyBase implementation in 2.6 
> and 3.0 that explicitly delegates all of the C-level slots to a 
> designated target instance? For some proxy class implementers, it 
> would be possible to use this class as a base-class to get the special 
> method delegation 'for free', and for others with more esoteric needs, 
> it would at least provide a reference for which special methods needed 
> to be provided explicitly by the proxy type.
>
> I attached a sample implementation to [1] which is essentially 
> equivalent to weakref.proxy, but with a strong reference to the 
> target, and written in Python rather than C.
>
> I expect the target audience for such a feature to be quite small, but 
> without better support for it in the standard library, I also suspect 
> it could prove to be a show-stopper for the affected developers as far 
> as Py3k migration is concerned.
>
> Cheers,
> Nick.
>
> [1] http://bugs.python.org/issue643841
>