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

[Guido van Rossum]

[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?

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

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

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

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

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)