Adding attributes to the request object

I have a case where a class method is the recipient of some data, parses it, and returns a particular data type containing a subset of that data. A second method, several steps removed from the original, needs to obtain a bit of data that would normally be disposed of in that first method. Several other parts of the site rely on that first method so because of that, and because of how far removed they are, I am loathe to refactor the api and/or data types in several locations to get this to work. It also shouldn't live beyond this request so setting it in the db is not a good idea.

It makes sense to me to just update the request object. The first method would be modified to get this special data and assign it to the request object, the second method could extract it, and everything in between can just ignore it. This appears to work in simple tests. My concern is that doing this seems incredibly rare. I don't see this behavior anywhere else in Plone aside from low level Zope (building the actual, original request) and test cases. Are there any caveats I'm missing?

In my inherited Zope app this was used quite a bit. I have not experienced any downsides except that that kind of code is a bit surprising and harder to reason about.

Plone uses something like this for the caching of view related function calls.

I can concur Dieter's comment. In the Plone documentation there is even an example using annotations on the request object - which is probably a safer and yet more fancy way of storing data.

Despite of the mentioned suprise factor, I see no big issue there. Good documentation helps in that regard. :slight_smile:

Brilliant, I will use exactly that thank you. I guess the reason to use annotations is to avoid name conflicts on the request object?

Indeed. The annotation key is being used as namespace to avoid such name conflicts.