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
_______________________________________________
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
