[Types-sig] method binding

[Evan Simpson]

>> 2. Objects can delegate attribute fetching to __bases__ objects in almost
>> the same way current classes do, except that the fetched attribute is not
>> processed or hooked in any way (eg. you get raw functions instead of
>> methods).
>
>No `except ...' clause.  Not `almost': exactly.


Ah.  This is why I do these point-by-point summaries.  I seem to have
misread the following (from your original article):

>The bases of an object are just some places where the object looks for
>uncompilicated values, with no `maybe binding' rule.  Things it finds
>there are treated just the same way as things it finds in its own
>namespace.  This is what we see at present if we ask for an attribute of
>a class and get our answer from one of its bases.  So __bases__ provides
>for delegation, only nobody'd commented on it.

I took "no `maybe binding' rule" to mean that functions aren't wrapped as
methods or bound to an instance.

>By contrest, after
>
>b = B()
>
>b.fred is munged, but that's because the lookup went via the b->B class
link.
>
>> 3. Objects can also delegate attribute fetching to __classes__ objects,
or
>> more specifically, to their __getinstattr__ functions.
>
>That specific is important.  It would probably make sense to replace the
>__classes__ list I involved with the list of __getinstattr__ callables.

This confuses me even more.  It seems that you are saying that "fred" access
through "b" is automatically shunted to the "fred" attribute of "B", as
though "B" were a base of "b", not a class.  "B" certainly doesn't seem to
be or have a callable which could find and return "fred"s value.

>> How do you spell something which acts like classes do now?
>Just the way we do at present, I'd reckon.
>
[snip]
>> How do you choose to treat an object as a class when handling it
>> directly (not through delegation from an 'instance')?
>
>I haven't understood this question.
>So the following may be off topic.


I'm really not sure how your proposal differs from current Python anymore,
except possibly in allowing an instance to have multiple classes (how?).
You *have* suggested that attributes are fetched from an object in different
ways depending on whether they are found in a __classes__ search or a
__bases__ search (I think).  Thus we get "fred" from "B" differently if "B"
is a base of "b" than if it is a class of "b".  Given that, how does one go
about accessing an attribute of "B" DIRECTLY (not through "b") in these two
different manners?  Only be calling B.__get*__?