This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nother
Recipients nother
Date 2019-06-23.13:59:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1561298384.82.0.239193690622.issue37379@roundup.psfhosted.org>
In-reply-to
Content
Not sure where to file this suggestion properly and how.

Currently when mixing attributes and properties it can happen that an AttributeError not raised intentionally by @property getter can cause @property to vanish from from classinstance. This happens when on the class or any of its super classes __getattr__ method is defined and has no clue on how to handle attribute with name of property. In this case the latter is reported as not existent.

The understood purpose of this behavior is that this is the only means to enable @property getters to indicate the availability of the property for a specific class instance dependent upon local state of instance object. Another purpose is to implement canonical load/creation on deemand schema for @properties the same way as for attributes.

The down of this is that in case inside a more complex getter method an AttribteError is triggered unintentionally this also triggers call to __getattr__ whithout any means for the latter to figure whether the @property getter needs assistance or the error should be passed on unhandled.

Therefore i do suggest the following little change to slot_tp_getattr_hook method in file typeobject.c (github python/cpython master) on lines 6604 - 6607 from

`
if (res == NULL && PyErr_ExceptionMatches(PyExc_AttributeError)) {
        PyErr_Clear();
        res = call_attribute(self, getattr, name);
}
`

to 

`
if (res == NULL && PyErr_ExceptionMatches(PyExc_AttributeError)) {
        res = call_attribute(self, getattr, name);
        if ( res != NULL) {
             PyErr_Clear();
        }        
}
`

this little change would allow __getattr__ special method to 

  1) use plain raise (see pythoncode example attached) to reraise exception which caused the call to it

  2) allow @property getters convey by adding custom attribute to AttributteExcpetion  the reason for an intentionally raised AttributeError over to __getattr__ allowing for distinction between AttributeError raised to hide @property from class instance versus triggering load/creation on demmand for class instance vs AttributeError accidentially triggered by getter/setter/deleter code.


Still not possible would be for getattr and hasattr methods to figure whether the AttributeError is raised cause class instance does not have the requested attirbute or whether accessing the attribute or @property respekctive caused some there downstream an AttributeError. In case that would be reliably feasible at all.
History
Date User Action Args
2019-06-23 13:59:44nothersetrecipients: + nother
2019-06-23 13:59:44nothersetmessageid: <1561298384.82.0.239193690622.issue37379@roundup.psfhosted.org>
2019-06-23 13:59:44notherlinkissue37379 messages
2019-06-23 13:59:44nothercreate