[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