[Zope] Re: request.locale - do we have this in 2.9.4?

Philipp von Weitershausen philipp at weitershausen.de
Tue Sep 5 15:37:53 EDT 2006


Dieter Maurer wrote:
> Philipp von Weitershausen wrote at 2006-9-5 20:57 +0200:
>> ...
>> Note that I'm well aware of this issue and have thought hard about it. I 
>> think the only long term solution out of this mess is to get rid of the 
>> __getattr__ spelling once and for all.
> 
> The "__getattr__" may be a stumbling block in principle.
> 
> Practically, it will very rarely hinder you to add attributes (such as
> "locale") to the request.

I think "locale" and "debug" are just common enough to be form variables.

> True: you can use "REQUEST.locale" or "REQUEST.debug" and expect
> to access in fact "REQUEST['locale'] and "REQUEST['debug']" respectively.
> 
> But, it is rare that the attribute access syntax is used

You'd be surprised (I was too). Plus, TALES path expressions first try 
attribute access, then item access.

> and if it indeed results in the wrong result (because the request
> grew additional  attributes), then it is easy to fix.

Sure, but it's a BBB foul. It's not *me* who has the legacy code, so I 
wouldn't mind. But I'm sure others would.

> Adding the configuration option would (perhaps) make the administrator
> aware of the potential cause when he gets informed about wrong values
> read from the request.

Perhaps. A configuration option (that would usually be turned to 'off') 
would surely be a quick way of finding out where you have code that uses 
request.foo. It may be a good step leading an actual deprecation of the 
__getattr__ spelling (which I think is necessary for eliminating the 
reuquest.foo spelling once and for all, especially in newly created code).

Philipp


More information about the Zope mailing list