quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Looijmans <nlv11...@natlab.research.philips.com>
Subject Re: [jira] Commented: (MODPYTHON-93) Improve util.FieldStorage efficiency
Date Mon, 11 Sep 2006 11:05:26 GMT
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:
>     [ http://issues.apache.org/jira/browse/MODPYTHON-93?page=comments#action_12433818
] 
>             
> 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
>>                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: 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 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.
> 
> 


Mime
View raw message