[Python-Dev] [Python-3000] Betas today - I hope (original) (raw)

Guido van Rossum guido at python.org
Thu Jun 12 15:55:07 CEST 2008

[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 PyTypeLookup 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/)

More information about the Python-Dev mailing list