As I recall, dropping the current Trac version for 3.3 is what we wanted to do.

In addition, there was talk about implementing a __setitem__ method as well to support manual insertion of fields, so that FieldStorage becomes a real dictionary-like object. The add_field method was to be reworked so that it could be publicly available.

(side thought: Allowing population from code rather than only from a Request object might allow FieldStorage to be used in test code)

Mike Looijmans
Philips Natlab / Topic Automation

Graham Dumpleton (JIRA) wrote:
[ ] Graham Dumpleton commented on MODPYTHON-93:

Have we decided that we will not try and be compatible with Trac and expect 
people using mod_python 3.3 to use the next unreleased version of Trac? This 
next version of Trac works via a WSGI gateway and thus doesn't use FieldStorage 
and thus doesn't have the problems seen here. Can we mark the original issue as 
resolved for 3.3?

Improve util.FieldStorage efficiency

               Key: MODPYTHON-93
           Project: mod_python
        Issue Type: Improvement
        Components: core
  Affects Versions: 3.2.7
          Reporter: Jim Gallacher
       Assigned To: Jim Gallacher
          Priority: Minor
           Fix For: 3.3

       Attachments: modpython325_util_py_dict.patch

Form fields are saved as a list in a FieldStorage class instance. The class 
implements a __getitem__ method to provide dict-like behaviour.  This method 
iterates over the complete list for every call to __getitem__. Applications 
that need to access all the fields when processing the form will show O(n^2) 
behaviour where n == the number of form fields. This overhead could be avoided 
by creating a dict (to use as an index) when the FieldStorage instance is 
Mike Looijmans has been investigating StringField and Field as well. It is 
probably reasonable to include information on his work in this issue as well, 
so that we can consider all of these efficiency issues in toto.

Reply via email to