dunder-docs (was Python is DOOMED! Again!)

[Devin Jeanpierre]

On Mon, Feb 2, 2015 at 5:00 AM, Devin Jeanpierre <jeanpierreda at gmail.com> wrote:
> On Mon, Feb 2, 2015 at 4:06 AM, Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> wrote:
>>> On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
>>> <steve+comp.lang.python at pearwood.info> wrote:
>> Both K.f and K.g are methods, even though only one meets the definition
>> given in the glossary. The glossary is wrong.
>
> I agree, it oversimplified and has made a useless distinction here.

Oops, I just realized why such a claim might be made: the
documentation probably wants to be able to say that any method can use
super(). So that's why it claims that it isn't a method unless it's
defined inside a class body.

-- Devin

>>>> Even if it is so defined, the definition is wrong. You can define methods
>>>> on an instance. I showed an example of an instance with its own personal
>>>> __dir__ method, and showed that dir() ignores it if the instance belongs
>>>> to a new-style class but uses it if it is an old-style class.
>>>
>>> You didn't define a method, you defined a callable attribute.
>>
>> That is wrong. I defined a method:
>>
>> py> from types import MethodType
>> py> type(instance.f) is MethodType
>> True
>>
>>
>> instance.f is a method by the glossary definition. Its type is identical to
>> types.MethodType, which is what I used to create a method by hand.
>
> You are assuming that they are both methods, just because they are
> instances of a type called "MethodType". This is like assuming that a
> Tree() object is made out of wood.
>
> The documentation is free to define things in terms other than types
> and be correct. There are many properties of functions-on-classes that
> callable instance attributes that are instances of MethodType do not
> have, as we've already noticed. isinstance can say one thing, and the
> documentation another, and both can be right, because they are saying
> different things.
>
>
> For an example we can all agree on, this is not an instance of
> collections.Iterable, but the docs claim it is iterable:
> https://docs.python.org/2/glossary.html#term-iterable
>
>     class MyIterable(object):
>         def __getitem__(self, i): return i
>
> The docs are not "wrong", they are just making a distinction for
> humans that is separate from the python types involved. This is OK.
>
> -- Devin