Re: [Python-Dev] Issue 643841: Including a new-style proxy base class in 2.6/3.0
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
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
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
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
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
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
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
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
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
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
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
