Looking at request.py, it looks like there is already a precedent for handling this type of error with the wrap_attributeerror context manager defined at https://github.com/encode/django-rest-framework/blob/master/rest_framework/request.py#L68 and then used at

• https://github.com/encode/django-rest-framework/blob/master/rest_framework/request.py#L230
• https://github.com/encode/django-rest-framework/blob/master/rest_framework/request.py#L254
• https://github.com/encode/django-rest-framework/blob/master/rest_framework/request.py#L274

I've opened another PR (#9455) that utilizes this context manager through a safe_property decorator that is utilized by each of the properties in the Request class.

Description

To address #9433 (which is caused by python/cpython#90143) simply wraps AttributeErrors which are raised in the parse process into a ParseError.

can you please check the approach followed here please? #9455

@auvipy yes, that may work better.

I can also point out that the WrappedAttributeError it should be added every other properties (inside them, as it was pointed out that a custom decorator is slower).

I belive that "wrapping" the response may not be an optimal solution (I got in the past errors when handling with DRF requests in non-DRF code which was expecting an instance of HTTPRequest because there is no inheritance). However this would require a bigger rework and a deeper discussion.

Than I close this PR in favor or #9455.

PS: I am curious to see if the same issue would be raised by cached_property, this because many properties on DRF Request looks something which can also be implemented using that descriptor.