[Python-Dev] [Python-3000] Betas today - I hope

[Nick Coghlan]

Guido van Rossum wrote:
> [Barry]
>>>> http://bugs.python.org/issue643841
> 
> [Guido]
>>> I've added a comment. Let me know if anything I said is unclear.
> 
> On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> The bugtracker seems to be offline atm - I'll reply there once I can get to
>> it again (as well as switching this issue back to being a documentation
>> one).
>>
>> I don't think we're going to see a major clamor for a value-based delegation
>> mixin in the standard library until people using classic classes for
>> value-based delegation start making serious attempts to port to Py3k (where
>> that approach is no longer available). At the moment, such classes only need
>> to care about the methods they want to fiddle with, leaving everything else
>> to __getattr__ based delegation.
> 
> 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?

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.

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

>> so I'll start working on a documentation
>> patch for the language reference instead which explicitly splits the special
>> methods into the following categories:
> 
> Thanks for doing this, it is needed regardless!
> 
>> 1. Method lookup MUST bypass __getattribute__, shadowing the attribute in
>> the instance dictionary MUST NOT have any ill effects. (All tp_* C-level
>> slots and slots looked up via _PyType_Lookup will fit into this category)
> 
> Watch out: I think the term "method lookup" may be confusing here.
> Certainly when the user writes x.__foo__(), the instance dict *is*
> consulted. It is only on *implied* lookups (e.g. x[y] or x+y) where
> the instance dict is bypassed.

Ah good point, I'll make sure to be careful with that.

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

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

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org