Chris McDonough wrote:
As said, I think the first step towards unifying the request interfaces would be to deprecate the __getattr__ protocol for request variables. I think we should start with Zope 2.11.
I'm sure you know this, but I wanted to point out that doing this will break a lot of third-party code. A ton of third-party code relies on being able to use __setattr__ and __getattr__ on the request object to do per-request caching.
Yeah, I know. That's why we can't just stop supporting __{g|s}etattr__, but we'll have to 1st) discourage using it (use __getitem__ on the request, or even request.form, request.cookies, etc. instead), 2nd) deprecate it and 3rd) finally remove it. In either case, I think it would be much much easier in the long term if request.something would always be the 'something' method or attribute of the request object and not perhaps a form variable, a method or attribute...
Maybe we should just solve the "form.debug" problem for now in 2.11 (it's a method that is hardly ever, ever used, so it can likely be renamed without much of a problem) and see where that gets us?
The debug problem is already solved, albeit not in a very pretty manner. request.debug is just one attribute that we want to add to the Zope 2 request API, there are more in the line (see Rocky's wish for request.locale). The current behaviour with __getattr__ resolving to request variables first makes it insanely hard to extend the Zope 2 request API and have predictable access to request attributes. Hence I think deprecating __getattr__ access to request variables (forms, cookes) should be deprecated in the long term; __getitem__ is a much more reliable way to do this. Philipp