[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Docs updated for 3.0 in r66084 (and I was right in thinking the automatic merge didn't have a hope of getting this right - there were conflicts all the way through the file). Closing this issue after a mere 5 years and 9 months - any requests f

[issue643841] New class special method lookup change

Georg Brandl <[EMAIL PROTECTED]> added the comment: Ah, I'm sorry for the noise then. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bug

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: I meant to say that I will be merging it manually to avoid bringing the old-style class specific parts over (that's why I left the issue open and assigned to me). ___ Python tracker <[EMAIL PROTECTED]>

[issue643841] New class special method lookup change

Georg Brandl <[EMAIL PROTECTED]> added the comment: But don't the docs with patch describe the behavior of new-style classes better? ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Committed for 2.6 as r65487. I also blocked the automatic merge to 3.0 since the references to old-style classes don't make sense there. ___ Python tracker <[EMAIL PROTECTED]>

[issue643841] New class special method lookup change

Changes by Nick Coghlan <[EMAIL PROTECTED]>: -- components: +Documentation -Library (Lib) ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Attaching a documentation patch for the moment until I get some info back from Georg as to why I can't build the docs locally. Once I get my local doc build working again, I'll check the formatting and check it in. -- assignee: -> nco

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: There are both speed and correctness reasons for special methods being looked up the way they are, so the behaviour isn't going to change. Aside from providing additional details in the language reference on how special methods are looked up (a

[issue643841] New class special method lookup change

kundeng <[EMAIL PROTECTED]> added the comment: Hi, I was trying to implement a generic proxy class with some restricting behaviors and then I bumped into this complication. May I ask what the conclusion is going to be in the long run? I guess my question is that 1> is it just going to be a d

[issue643841] New class special method lookup change

Changes by Nick Coghlan <[EMAIL PROTECTED]>: ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: The outcome of discussion of this issue on python-dev was that the lookup methodology for the special methods needs to be better documented, especially for those cases where the instance *must* be bypassed in order to avoid metaclass confusion f

[issue643841] New class special method lookup change

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: Thanks for the pronouncement Guido. We will not let this issue hold up the beta releases. ___ Python tracker <[EMAIL PROTECTED]> __

[issue643841] New class special method lookup change

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I want to make this "bypass getattr" behavior mandatory for those operations that currently use it, forcing the issue for other implementations of Python. That's a doc change (but an important one!). There are probably many random places w

[issue643841] New class special method lookup change

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: The name Proxy seems too vague. This class is all about targeted delegation. Am curious, has this been out as a recipe; has it been used in combat yet? -- nosy: +rhettinger ___ Python tracke

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Note that I don't make any promises about the correctness of the ReST formatting in that latest patch - my Doc build is misbehaving at the moment, and I haven't had a chance to look at what is wrong with it.

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: New patch (proxymixin.diff) uploaded that correctly delegates __format__, as well as using an overridable return_inplace() method to generate the inplace operation return values. The _target attribute has also been made formally part of the publ

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: and "__print__" was meant to be "__unicode__"... ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: bleh, "application independent decision" in my last post should read "interpreter implementation dependent decision". ___ Python tracker <[EMAIL PROTECTED]> __

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: And (mainly for Barry's benefit) a quick recap of why I think this is necessary for Python 3.0: For performance or correctness reasons, the interpreter is permitted to bypass the normal __getattribute__ when looking up special methods such as _

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Unfortunately, the standard library doesn't tend to do this kind of delegation (aside from weakref.proxy, which implements the equivalent code directly in C), so there isn't a lot of standard library code that will benefit from it directly. How

[issue643841] New class special method lookup change

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: release blocker -> critical ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue643841] New class special method lookup change

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: This is a huge thread and I don't have time to look at the entire patch. However, it seems like the main purpose of the proxy class is to work around a basic deficiency in Python. Now, if this is a purposeful omissions (i.e. defined as pa

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Ah, that would answer my #XXX comment regarding that in the patch. Agreed, the best answer will be to factor out the _rewrap operation into a new class method. (Next week though...) ___ Python tracker <[EMAIL

[issue643841] New class special method lookup change

Adam Olsen <[EMAIL PROTECTED]> added the comment: The inplace operators aren't right for weakref proxies. If a new object is returned there likely won't be another reference to it and the weakref will promptly be cleared. This could be fixed with another property like _target, which by default

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Note that I'll be offline for the next few days, so I want be able to respond to any comments until some time next week. ___ Python tracker <[EMAIL PROTECTED]> ___

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: I've attached the latest version of the module as an actual patch against Python SVN. It differs slightly from the last version uploaded as separate files, in that in-place operations on a proxied object will no longer strip the proxy wrapper o

[issue643841] New class special method lookup change

Changes by Nick Coghlan <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10402/typetools.rst Tracker <[EMAIL PROTECTED]> ___ Py

[issue643841] New class special method lookup change

Changes by Nick Coghlan <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10390/test_typetools.py Tracker <[EMAIL PROTECTED]> __

[issue643841] New class special method lookup change

Changes by Nick Coghlan <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10389/typetools.py Tracker <[EMAIL PROTECTED]> ___ Pyt

[issue643841] New class special method lookup change

Changes by Nick Coghlan <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file10439/test_typetools.py Tracker <[EMAIL PROTECTED]> ___

[issue643841] New class special method lookup change

Changes by Nick Coghlan <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file10438/typetools.py Tracker <[EMAIL PROTECTED]> ___ Pytho

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Updated test cases and documentation to cover use of a descriptor for _target in a subclass, and uploaded most recent local copies of all 3 files. -- keywords: +patch versions: +Python 3.0 -Python 2.2.1, Python 2.2.2, Python 2.2.3, Pyth

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: The way to override _deref/_unwrap is to make _target a property on a ProxyMixin subclass (which reminds me, I want to put in an explicit test case to make sure that works as intended - I'll use the weakref-proxy-in-Python as the example, so I'

[issue643841] New class special method lookup change

Adam Olsen <[EMAIL PROTECTED]> added the comment: Surely remote proxies fall under what would be expected for a "proxy mixin"? If it's in the stdlib it should be a canonical implementation, NOT a reference implementation. At the moment I can think up 3 use cases: * weakref proxies * lazy load p

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: As to the rationale for having it in the standard library: it's because of the coupling with the implementation of the type() builtin. If a new slot is added to type() that the interpreter may access without consulting __getattribute__, then Pro

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Specialised? What's specialised about it? It's designed to serve as a replacement for the simple delegation use cases that are currently met quite adequately by classic classes, since those are no longer available in 3.0. __

[issue643841] New class special method lookup change

Changes by Jesús Cea Avión <[EMAIL PROTECTED]>: -- nosy: +jcea Tracker <[EMAIL PROTECTED]> ___ Python-bugs-list mailing list Unsubsc

[issue643841] New class special method lookup change

Adam Olsen <[EMAIL PROTECTED]> added the comment: If it's so specialized then I'm not sure it should be in the stdlib - maybe as a private API, if there was a user. Having a reference implementation is noble, but this isn't the right way to do it. Maybe as an example in Doc or in the cookbook.

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Correct, this isn't intended to be an all-singing, all-dancing proxy implementation - it's meant to be a simple solution for local proxies that want to change the behaviour of a few operations while leaving other operations unaffected. The prop

[issue643841] New class special method lookup change

Adam Olsen <[EMAIL PROTECTED]> added the comment: _deref won't work for remote objects, will it? Nor _unwrap, although that starts to get "fun". Tracker <[EMAIL PROTECTED]> ___

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Also changed to a library issue instead of a docs issue. -- components: +Library (Lib) -Documentation Tracker <[EMAIL PROTECTED]> ___

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Added documentation, and assigned to Barry as release manager for 2.6/3.0. Also bumped to 'release blocker' status because I think the loss of classic classes transparent proxying capabilities is a fairly substantial issue that needs to be addr

[issue643841] New class special method lookup change

Changes by Jesús Cea Avión <[EMAIL PROTECTED]>: -- nosy: +jcea Tracker <[EMAIL PROTECTED]> ___ Python-bugs-list mailing list Unsubsc

[issue643841] New class special method lookup change

Changes by Nick Coghlan <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file10390/test_typetools.py Tracker <[EMAIL PROTECTED]> ___

[issue643841] New class special method lookup change

Changes by Nick Coghlan <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10385/typetools.py Tracker <[EMAIL PROTECTED]> ___ Pyt

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Attached a new version of the module, along with a unit test file. The unit tests caught a bug in the __gt__ implementation. I've also changed the name to ProxyMixin as suggested by Adam and switched to using a normal __init__ method (there was

[issue643841] New class special method lookup change

Adam Olsen <[EMAIL PROTECTED]> added the comment: Is there any reason not to name it ProxyMixin, ala DictMixin? -- nosy: +Rhamphoryncus Tracker <[EMAIL PROTECTED]>

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: I've attached a sample ProxyBase class that delegates all of the special methods handled by weakref.proxy (as well as the tp_oct and tp_hex slots, which weakref.proxy ignores). While there are other special methods in CPython (e.g. __enter__ an

[issue643841] New class special method lookup change

John Krukoff <[EMAIL PROTECTED]> added the comment: I've been following the py3k maliing list disscussion for this issue, and wanted to add a note about the proposed solution described here: http://mail.python.org/pipermail/python-3000/2008-April/013004.html The reason I think this approach is

[issue643841] New class special method lookup change

Piet Delport <[EMAIL PROTECTED]> added the comment: Somewhat related: #2605 (descriptor __get__/__set__/__delete__) -- nosy: +pjd Tracker <[EMAIL PROTECTED]> __

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: I spent an enlightening evening browsing through the source code for weakref.proxy. The way that code works is to define every slot, delegating to the proxied object to handle each call (wrapping and unwrapping the proxied object as needed). Th

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: I've started a discussion on the Py3k development list regarding the possibility of adding a new method to type to aid in converting proxy classes from classic- to new-style. Tracker <[EMAIL PROTECTED]>

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Agreed that section of the docs should be more explicit in pointing out that __getattr__ and __getattribute__ won't work for proxying special methods for new-style classes. It's also true that there are quite a few special methods where nothing

[issue643841] New class special method lookup change

John Krukoff <[EMAIL PROTECTED]> added the comment: I assume when you say that the documentation has already been updated, you mean something other than what's shown at: http://docs.python.org/dev/reference/datamodel.html#new-style-and- classic-classes or http://docs.python.org/dev/3.0/reference

[issue643841] New class special method lookup change

Nick Coghlan <[EMAIL PROTECTED]> added the comment: The 2.6 and 3.0 documentation has already been updated appropriately. The forward compatible way to handle this is to inherit from object and override the special methods explicitly in the 2.x version (Yes this can make writing proxy objects mor

[issue643841] New class special method lookup change

John Krukoff <[EMAIL PROTECTED]> added the comment: I was just bit by this today in converting a proxy class from old style to new style. The official documentation was of no help in discoverting that neither __getattr__ or __getattribute__ are used to look up magic attribute names. Even the link