[Zope-dev] Re: zope2 requests VS zope3 requests

Philipp von Weitershausen philipp at weitershausen.de
Sun May 28 11:12:33 EDT 2006


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


More information about the Zope-Dev mailing list