[-python-dev] [Guido] >> Whether they'll care about this issue of course depends on whether >> they need overloaded operators and other special delegations to be >> delegated transparently. We'll have to see how important this is. >> New-style classes have been around and recommended for a long time -- >> why haven't people pushed for a proxy class before?
On Thu, Jun 12, 2008 at 7:50 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > There was an easier way to do it in the form of classic classes - the 2,x > interpreter is riddled with special cases that ensure that __getattr__ is > always consulted when looking for special methods on a classic class. The > tracker issue regarding the fact that things aren't so simple with new style > classes was actually raised way back in 2002 when someone tried to port such > a class to new-style and discovered that overriding __getattribute__ was no > longer enough. And all that time people have been using classic classes as a crutch rather than developing a future-proof approach? I can't believe that. I think we should look for some existing proxies so we can identify best practice and perhaps improve upon. (Sorry if that's what you did, I haven't checked.) >>> I've pushed as hard as I'm personally willing to for this without >>> convincing >>> anyone else that it's worth doing, >> >> What does *it* refer to? Changing the behavior, or adding a proxy >> class to the stdlib? I'm -1000 on the former, but only -0 on the >> latter -- as I wrote in the tracker, I just don't want to see an >> unproven proxy class (and I don't like the module name). > > "It" referred to adding the proxy class - I'm personally ambivalent on > adding it at this point, because the complexity of it reduces my confidence > that I got it right, Also Michael Foord just wrote "I would prefer it if the proxy class wrapped the return values of inplace operations" -- which sounds like one reason why it's hard to have a one-size-fits-all proxy class, since when to wrap and when not to is probably very application dependent. > but it also makes it seem unfair to users of this > feature of classic classes to take it away in 3.0 without giving them some > kind of functional replacement. > > As for as the module name goes, I don't particularly like it either - > dropping something in the types module instead would be an alternative > option. No! Not the doomed types module! :-) [...] >>> 2. Method lookup MAY bypass __getattribute__, shadowing the attribute in >>> the instance dictionary MAY have ill effects. (slots such as __enter__ and >>> __exit__ that are looked up via normal attribute lookup in CPython will >>> fit into this category) >> >> Why even have a MAY category? Are you expecting these to become tp_ >> slots at some point? > > Either tp_* slots, or just having the invocation bypass the instance > attributes and only look at the object's type. > > I think it would actually be desirable for this category to be empty from a > purity point of view (with all the special methods in category 1), but given > that CPython itself currently doesn't conform to such a language spec, this > seems to be the next best option (i.e. allowing other implementations or > later versions of CPython to put these special methods in category 1 along > with the rest of the special methods) OK, fair point. >>> 3. Technically a subcategory of group 1, these are special methods which >>> can affect the interpreter's behaviour by their mere definition on a type. >>> (The __get__, __set__ and __delete__ descriptor protocol methods fall into >>> this category) >> >> I don't follow why this is relevant. This is a different, AFAIK >> orthogonal issue, used in many places: *if* an object used in a >> certain context has a specific attribute, *then* that attribute is >> used, *otherwise* a default action is taken. Applies to __repr__ just >> as much. These belong in category 1 if and only if the lookup bypasses >> the instance dict. > > Actual hasattr() checks aren't a problem - those hit __getattribute__ and a > delegating class can correctly check them against the target object. I never said hasattr(). AFAIK what happens sometimes is that _PyType_Lookup() is called and if it returns NULL the default action is used. > Methods > like __str__ or __repr__ also aren't a major issue - those are easy to > delegate in a way that reproduces the same behaviour as if the delegating > class wasn't there (just reinvoke the appropriate builtin on your target > object). > > This category is specifically for method checks in category 1 which bypass > __getattribute__ *and* have significant effects on the way an object gets > handled that can't be readily dealt with by a value-based delegation class - > the most significant methods I've actually found in that category so far are > the descriptor protocol methods (that's why my ProxyMixin class skipped > delegating them). Ah, now I understand. These are things that you shouldn't define in the proxy class if the target class doesn't define it. I think I've seen solutions that dynamically define a proxy class depending on whether the target class implements a certain special method or not. > As long as the callable() builtin is around, __call__ actually lands in this > category as well (since defining it will affect the answer returned by the > callable() builtin). Being able to return different proxy classes with and > without __callable__ defined is actually the reason weakref.proxy is a > factory function rather than a type in its own right. What I said. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
