classification
Title: Descriptor instance attributes not interpreted consistently
Type: behavior Stage:
Components: Interpreter Core, Library (Lib) Versions: Python 3.0, Python 2.4, Python 2.3, Python 2.2.3, Python 2.6, Python 2.2.2, Python 2.5, Python 2.2.1, Python 2.2
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: gvanrossum, pjd
Priority: normal Keywords:

Created on 2008-04-10 10:15 by pjd, last changed 2008-06-11 16:46 by gvanrossum. This issue is now closed.

Messages (4)
msg65289 - (view) Author: Piet Delport (pjd) Date: 2008-04-10 10:15
Short version:  __get__/__set__/__delete__ attributes on descriptor objects
(as opposed to their types) are treated inconsistently as part of the
descriptor
protocol:  the documentation and support code includes them;  the core
implementation doesn't.

Example:

    class D(object):
        __get__ = lambda self, i, o: 'D'

    class C(object):
        d = D()
        d.__get__ = lambda i, o: 'd'
        d.__set__ = lambda i, v: 1/0

    c = C()

According to pydoc and inspect, and the description in the reference manual
(section 3.4.2.3), d's __get__ and __set__ override D's:

    >>> inspect.isdatadescriptor(C.__dict__['d'])
    True
    >>> help(C)
    class C(__builtin__.object)
    |  Data descriptors defined here:
    ...
    |  d

    >>> type(c).__dict__['d'].__get__(c, type(c))
    'd'
    >>> type(c).__dict__['d'].__set__(c, 5)
    ZeroDivisionError: integer division or modulo by zero

According to CPython, they have no effect:

    >>> c.d
    'D'
    >>> c.d = 5; c.d
    5

PEP 252 notes: "For speed, the get and set methods are type slots", which
points to the CPython behavior being an intentional concession for
performance.

Should CPython respect descriptor object attributes, if reasonable
performance
can be maintained?  Otherwise, should the documentation and support code be
changed to ignore them?
msg65574 - (view) Author: Piet Delport (pjd) Date: 2008-04-17 05:40
Related: #643841 (new-style special method lookup)
msg65578 - (view) Author: Piet Delport (pjd) Date: 2008-04-17 06:48
From the Py3K list: 
http://mail.python.org/pipermail/python-3000/2007-March/006304.html

The sentiment appears to be to leave the behavior
implementation-defined.  It seems straightforward to update inspect and
pydoc to mirror typeobject.c, but i'm not sure where this leaves the
documentation.
msg67993 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-06-11 16:46
The behavior observed is intentional.  The docs should be updated.
History
Date User Action Args
2008-06-11 16:46:33gvanrossumsetstatus: open -> closed
resolution: rejected
messages: + msg67993
nosy: + gvanrossum
2008-04-17 06:48:05pjdsetmessages: + msg65578
2008-04-17 05:40:31pjdsetmessages: + msg65574
2008-04-10 10:15:08pjdcreate