[Zope-dev] Re: Pointless code in ZPublisher.HTTPRequest ?
yuppie
y.2004_ at wcm-solutions.de
Tue Aug 31 15:51:26 EDT 2004
Hi!
Paul Winkler wrote:
>>From ZPublisher.HTTPRequest.HTTPRequest.keys:
>
> n=0
> while 1:
> n=n+1
> key = "URL%s" % n
> if not self.has_key(key): break
>
> n=0
> while 1:
> n=n+1
> key = "BASE%s" % n
> if not self.has_key(key): break
>
> Unless I am particularly stupid today (quite possible),
> the above has no affect on the return value, and no
> direct side effects.
>
> I tried commenting it out and ran all unit tests
> with no apparent difference.
>
> While digging deeper for indirect side effects, I see that
> self.has_key() calls self.__getitem__() which calls self.get().
> The only side effect of self.get('URLn') that I see is that if
> self.other.has_key('PUBLISHED'), the calculated URL will get
> cached for the duration of the request in self.other['URLn'].
> [...]
>
> So maybe that's the sole purpose of the code in question;
> some extra logging suggests that it does in fact have that effect.
> But it's hard for me to be sure.
> Can anyone confirm or deny?
> Or is there something else that I'm missing?
In situations like that the CVS history is often quite useful:
<http://cvs.zope.org/Zope/lib/python/ZPublisher/Attic/HTTPRequest.py.diff?r1=1.17&r2=1.18>
I'd say the sole purpose is what you describe, but the result of the
side effect is used in the next line of 'keys':
keys.update(self.other)
This small script shows that the code in 'keys' triggers the computing
of URLx and BASEx:
print context.REQUEST.other.keys()
context.REQUEST.keys()
print context.REQUEST.other.keys()
return printed
Cheers,
Yuppie
More information about the Zope-Dev
mailing list