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

2008-05-28 Thread Michael Foord

Greg Ewing wrote:

Nick Coghlan wrote:


else:
# Returned a different object, make a new proxy
result = type(self)(result)


You might want to check that the result has the
same type as the proxied object before doing that.


Yep - and I really think it would need to do this. To have a proxy where:

proxy_instance += 1

unwraps the proxy is really no good! (At least not for my use cases...)

Michael Foord

--
http://www.ironpythoninaction.com/
http://www.theotherdelia.co.uk/
http://www.voidspace.org.uk/
http://www.ironpython.info/
http://www.resolverhacks.net/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2008-05-27 Thread Greg Ewing

Nick Coghlan wrote:


else:
# Returned a different object, make a new proxy
result = type(self)(result)


You might want to check that the result has the
same type as the proxied object before doing that.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2008-05-27 Thread Greg Ewing

Armin Ronacher wrote:

I'm currently not
providing any __r*__ methods as I was too lazy to test on each call if the
method that is proxied is providing an __rsomething__ or not, and if not come up
with an ad-hoc implementation by calling __something__ and reversing the
arguments passed.


I don't see why you should have to do that, as the reversed
method of the proxy will only be called if a prior non-reversed
call failed.

All the proxy should have to do is delegate any lookups of its
own reversed methods to corresponding methods of the proxied
object, no differently from any other method.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2008-05-22 Thread 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   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2008-05-21 Thread 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.


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   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2008-05-21 Thread Fred Drake

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.


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


  -Fred

--
Fred Drake   




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2008-05-21 Thread Nick Coghlan

Fred Drake wrote:

Nick Coghlan wrote:
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?



On May 20, 2008, at 7:55 PM, Greg Ewing wrote:

Sounds good to me.


Same here.  There's an implementation in zope.proxy which might be 
useful as a starting point:


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).


One other issue is where to put it - none of the existing stdlib modules 
seemed appropriate, so my sample implementation in the tracker issue 
just invents a new 'typetools' module.


Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2008-05-20 Thread Fred Drake

Nick Coghlan wrote:
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?



On May 20, 2008, at 7:55 PM, Greg Ewing wrote:

Sounds good to me.


Same here.  There's an implementation in zope.proxy which might be  
useful as a starting point:


http://pypi.python.org/pypi/zope.proxy/3.4.0

I'd be willing to write the required documentation, since I'm partly  
to blame for the implementation.


The short description of the package on PyPI contains a typo; that's  
been fixed in Subversion.  :-)



  -Fred

--
Fred Drake   




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2008-05-20 Thread Greg Ewing

Nick Coghlan wrote:
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?


Sounds good to me.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2008-05-20 Thread 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



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2008-05-20 Thread Nick Coghlan
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.


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

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com