On Tue, 2004-09-14 at 22:49, Richard Jones wrote:
Yup. IOW, it looks like it used to find the first "secure_url" it could access and return that, even if there were other acquirable "secure_url" attrs before that one in the acquisition path. I'm sure the fact that it ignores any intermediate (but inaccessible) "secure_url" attrs is what Tres meant by DWIM.
I *think* you're implying that there might be more than one secure_url attribute in the acquisition path? If so, that's not the case. There is only one, and it's on B.
Yup.
Or perhaps what you're saying is that in the pre-patch days, if there *was* an attribute on A, then validate() would do the Wrong Thing, or something otherwise bad would happen.
In the pre-patch days, guarded getattr did "validate" on basically every object in the acquisition chain and returned the first attribute that the user could access in that chain. Now guarded_getattr relies on whatever "validate" does when it receives the top-level object and doesn't try to do anything fancy to find an accessible attribute. I'd just stick the code back in there for now and we'll see what Tres says.
I'm a little confused about why I'm the only person seeing this, BTW...
Me too. It'd be nice if "A" had a secure_url attribute, then it might even be explicable. I don't have the patience at the moment to pdb through validate, so I can only guess why it is actually happening. ;-)
But I'm not sure that he intended for the patch to have this effect. I'm not even sure why it does have this effect; the "validate" function is just too byzantine to understand without taking it through the debugger.
You can say that again. My head hurts every time I need to look into validate() and friends ;)
It could be worse, you could have found a problem in BaseRequest.traverse. ;-) - C