Graham Dumpleton wrote:
Jim Gallacher wrote ..
Graham Dumpleton wrote:
On JIRA, the following issues are still marked as incomplete for mod_python
version 3.3. I have noted my own comments about where they are up to
and
what I think still needs to be done.

MODPYTHON-93 Improve util.FieldStorage efficiency.

This was actually marked as resolved but reopened because it was discovered
that changes meant that Trac <=0.9.6 would no longer work. The changes
were
also backed out of mod_python 3.2.X branch and not released in 3.2.10.

At this point I believe we have agreed that code in 3.3 would be left
as is and
people would need to use Trac >=0.10, which has now been release, with
mod_python 3.3 or later.
I know we've hashed this over a couple of times, but creating this dependency still makes me nervous.

I'll see if I can get a chance to see what the issue is and what it would take
to still support Trac then.

As I recall, Trac 0.9.6 wraps FieldStorage and wants to manipulate the the internal list. We changed the behaviour of that list, so now it fails.

The relevant bit of code is in trac/web/modpython_frontend.py in their FieldStorageWrapper class.


class FieldStorageWrapper(util.FieldStorage):
    """
mod_python FieldStorage wrapper that improves compatibility with the other
    front-ends.
    """

    def __init__(self, req):
        """
        The mod_python FieldStorage implementation, unlike cgi.py, always
includes GET parameters, even if they are also defined in the body of a POST request. We work around this to provide the behaviour of cgi.py
        here.
        """
        class RequestWrapper(object):
            def __init__(self, req):
                self.req = req
                self.args = ''
            def __getattr__(self, name):
                return getattr(self.req, name)
util.FieldStorage.__init__(self, RequestWrapper(req), keep_blank_values=1)

# Populate FieldStorage with the original query string parameters, if
        # they aren't already defined through the request body
        if req.args:
            qsargs = []
            for pair in util.parse_qsl(req.args, 1):
                if self.has_key(pair[0]):
                    continue
                qsargs.append(util.Field(pair[0], StringIO(pair[1]),
                                         "text/plain", {}, None, {}))
            self.list += qsargs

    def get(self, key, default=None):
        # Work around a quirk with the ModPython FieldStorage class.
        # Instances of a string subclass are returned instead of real
        # strings, this confuses psycopg2 among others.
        v = util.FieldStorage.get(self, key, default)
        if isinstance(v, util.StringField):
            return v.value
        else:
            return v

    def __setitem__(self, key, value):
        if value is not None and key not in self:
            self.list.append(util.Field(key, StringIO(value), 'text/plain',
                             {}, None, {}))


There are a couple of things that can be cleaned up and marked as closed.

Add get_session() method to request object.
http://issues.apache.org/jira/browse/MODPYTHON-59

This idea was pretty much shot down, but there is still a bit of residual code that should be cleaned up. I'll do that and mark it as closed. I think the idea still has merit, but it would be better to start from scratch at some future date.

Agree, code should be taken out and issue revisited at a later time if 
warranted.

Although there is no JIRA issue for it, I'd like to see us do a quick code cleanup. I see lots of complier warnings about unused variables and
it would be nice to excise the offending bits of code. I figure we are
more likely to spot real problems if the compiler is spewing less noise.
If there are no objections I'll do this over the weekend.

Hmmm, I thought I had gone through and got rid of just about all of them.
The only ones which I didn't fix up were some of the magic Python callbacks
for deleting objects or something.  I couldn't change these as I don't think
some appropriate typedef or something existed in older versions of Python
we still support.

You may well be correct. It's been a while since I sat and watched the
compiler output and that may have been when I was doing some leak
testing on 3.2.10.

Overall I'd say we are in pretty good shape - thanks mainly to Graham's
hard work. If we defer the Python 2.5 / 64-bit support though I think we
should aim for a quick turnaround on a mod_python 3.4 release. Maybe a
January or February time frame?

Jim



Reply via email to