[Zope-dev] makerequest issues

Paul Winkler pw_lists at slinkp.com
Fri Mar 31 12:31:55 EST 2006


Several things:

1) there is a "makerequest" function in both Testing/makerequest.py
and Testing/ZopeTestCase/utils.py.  They are subtly different.
Is there a deliberate reason for this?  I notice that the one
in utils.py lacks the recent fix for zope 3 views, and the one
in makerequest.py lacks an ACTUAL_URL.

2) re. the bug which I just posted at
http://www.zope.org/Collectors/Zope/2057
the issue is that if you have something that inherits
Traversable, and wrap it with makerequest(), its
getPhysicalPath() method is broken, because getPhysicalPath()
tries to call getPhysicalPath() on all non-None aq_parents,
and an HTTPRequest isn't Traversable.

There are two possible fixes to that bug:

I could hack around it in makerequest() by adding a fake
getPhysicalPath().  I've uploaded a patch to the collector
that does this.

- or -

I could change the conditional in Traversable.getPhysicalPath to look
like so:

    def getPhysicalPath(self):
        ...
        p = aq_parent(aq_inner(self))
        if p is not None and getattr(p, 'getPhysicalPath', None) is not None:
            path = p.getPhysicalPath() + path
        ...

I was reluctant to do the latter because of two worries:

a) I figured it's called all over the place and even slightly adding to
its workload might negatively impact performance; the attached timeit
script shows about a 15% slowdown in the method, however, I've not been
able to measure any difference when hitting a default plone front page
with ab.

b) I don't know if there is code that relies on the current behavior of
getPhysicalPath(), i.e. raise an AttributeError if p is something
other than None but still lacks getPhysicalPath.

I can't imagine a use case, but who knows...

Opinions?

-- 

Paul Winkler
http://www.slinkp.com


More information about the Zope-Dev mailing list