[Python-Dev] __objclass__ documentation

[Ethan Furman]

On 10/13/2013 04:44 AM, Nick Coghlan wrote:
> On 13 Oct 2013 08:27, "Ethan Furman" <ethan at stoneleaf.us> wrote:
>>
>> It was pointed in Issue16938[1] that __objclass__ is not documented anywhere.
>>
>> Is the following an appropriate description? (in Doc/reference/datamodel.rst in user-defined functions)
>>
>>
>>
>>        +-------------------------+-------------------------------+-----------+
>>        | :attr:`__objclass__`    | The class this object belongs |           |
>>        |                         | to; useful when the object is |           |
>>        |                         | a descriptor, or a virtual or |           |
>>        |                         | dynamic class attribute, and  |           |
>>        |                         | it's __class__ attribute does |           |
>>        |                         | not match the class it is     |           |
>>        |                         | associated with, or it is not |           |
>>        |                         | in that class' ``__dict__``.  |           |
>>        +-------------------------+-------------------------------+-----------+
>
> I think this is inaccurate. The meaning of __objclass__ as described
> in PEP 252 is to denote unbound callable descriptors that only work
> with a specific type. That's why it's mostly gone in Python 3.

PEP 252 has this comment:

     [Editor's note: the ideas described in this PEP have been incorporated
      into Python.  The PEP no longer accurately describes the implementation.]


> It should be documented, but the documentation should say something like:
>
> __objclass__: Indicates this callable requires an instance of the
> given type (or a subclass) as its first positional argument. For
> example, CPython sets this for unbound methods that are implemented in
> C rather than Python.

> The offending block of code in the inspect module
> (http://hg.python.org/cpython/file/default/Lib/inspect.py#l366) that
> prompted http://bugs.python.org/issue16938 just looks flat out broken
> to me. There's *zero* reason to expect that __class__ on the result of
> retrieving an attribute from an object will appear in the MRO for that
> object. I just missed that detail when reviewing
> http://bugs.python.org/issue19030 :)

Actually, it's the other way around -- the code currently in inspect.py at that point was prompted by this issue (and 
tracked in Issue 19030).  Interestingly enough, with the current changes in 16938 I can remove the __objclass__ 
attribute I had added to Enum to get around this.

--
~Ethan~