Graham Dumpleton commented on MODPYTHON-93:

I have committed some changes into repository now which
fixes the issue with add_field() but also does things in such a way that
code such as Trac which creates Field instances direct and adds them
to the the list of form fields will still work. It does this by using a
derived list class instance which invalidates the key lookup table on
changes to the list so that the lookup table is rebuilt the next time
it is required. Doing this wasn't as bad as I first thought it would be
as hadn't gone to the extent of properly understanding the code before.
Also include a semi hack in Field class constructor to detect old style
use where code expects more than just the name of the field as
argument and do appropriate initialisation as appropriate.

In all, what the changes allow is for the following to work:

from mod_python import util
from StringIO import StringIO

def index(req):
  req.content_type = 'text/plain'

  req.write('%s\n\n' % req.form.keys())

  for key in req.form.keys():
    req.write('%s %s\n' % (key, req.form.getlist(key)))


  req.form.add_field('e', 'f')

  req.form.list.append(util.Field('g', StringIO('h'),
      "text/plain", {}, None, {}))
  req.form.list.extend([util.Field('i', StringIO('j'),
      "text/plain", {}, None, {})])
  req.form.list += [util.Field('k', StringIO('l'),
      "text/plain", {}, None, {})]

  req.write('%s\n\n' % req.form.keys())

  for key in req.form.keys():
    req.write('%s %s\n' % (key, req.form.getlist(key)))


  return None

If this is accessed with:


I get:

['a', 'c', 'e']

a [Field('a', 'b')]
c [Field('c', 'd')]
e [Field('e', 'f')]

['a', 'c', 'e', 'g', 'i', 'k']

a [Field('a', 'b')]
c [Field('c', 'd')]
e [Field('e', 'f'), Field('e', 'f')]
g [Field('g', 'h')]
i [Field('i', 'j')]
k [Field('k', 'l')]

As the req.form.keys() method works off the lookup table, you can see
how updates direct to list work okay, meaning stuff like Trac should

You will also note that the 'dictionary' attribute has gone and is hidden
elsewhere. Hopefully people will not try and directly access the
equivalent, but some stern notes in the documentation saying only
to use documented interface might help. :-)

If we can test the updates and especially if someone can test it with
older versions of Trac that would be great, but even if we can't will
mark issue as resolved after a short wait.

> Improve util.FieldStorage efficiency
> ------------------------------------
>                 Key: MODPYTHON-93
>                 URL: http://issues.apache.org/jira/browse/MODPYTHON-93
>             Project: mod_python
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 3.2.7
>            Reporter: Jim Gallacher
>         Assigned To: Graham Dumpleton
>            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 created.
> 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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: 
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to