Paul Winkler wrote:
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':
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
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce