Descriptor: class name precedence over instance name

[Veek. M]

Ben Finney wrote:

> "Veek. M" <vek.m1234 at gmail.com> writes:
> 
>> Trying to make sense of this para:
> 
> At the risk of being ruse, I am trying to make sense of some
> paragraphs in the messages you write here. Could you take a little
> more time to write clearly, as a way of communicating in this forum?
> 
>> Is he say that Descriptors are a special case where Foo is checked
>> first, then what - Base classes..? or does he hop back to look in the
>> instance? How is C3 Linearization altered?
> 
> I really have no idea what this paragraph means. Can you please write
> again assuming we don't know already what you are trying to say?
> 

Sorry about that, I found it hard to read too (when I came back to it). 

I was trying to figure out the order in which attributes are looked up. 
Beazley's a great book, but sometimes he kills me and mounts my head on 
a pike - page 127 - Descriptors section, last para.

He says that descriptor-attribute-names in a class, take precedence in a 
attribute lookup wrt instance attributes.

When you do an x.a, python goes on a hunt for 'a' - the whole binding 
idea; typically, that is, Instance Name Space -> Class NS -> BaseClasses
(C3 Linearization algorithm)

Therefore, I was wondering how he could start the search at the 
instance-Class, instead of the instance. When you print __mro__ you get 
a list of classes that are traversed but there's no explicit mention 
within the __mro__ that the instance is searched first. So I wanted to 
know if there was any implications to C3/__mro__

So essentially from what Ian said:
data_descriptor_in_instance -> instance_attribute -> non-
data_descriptor_in_instance -->__mro__

is how the search takes place. Correct?
------------------------------

Regarding part2 of the Q, :) Ian hasn't explained it, so I'm not sure 
how to explain it better :) but i'll try given that he has clarified 
part of the answer.

Basically Beazley has a TypedProperty descriptor class, and in class Foo
he instantiates:
 name = TypedProperty
Then he does f = Foo()

Thanks to Ian, we now know that any lookup on 'f' eg: f.name would 
cause.. well.. the f.name(TypedProperty-descriptor) to gain precedence 
thus hiding the f.name attribute! Therefore he needs to name-decorate or 
in this example append an '_' for whatever stupid reason.

I think i've got the jist down pat so :p
Here's the image:
http://storage1.static.itmages.com/i/16/0702/h_1467451175_7972040_b5037f6b46.png

(thanks Ian)