|
If you were logged in you would be able to see more operations.
|
|
|
| Resolution Date: |
22/Nov/06 11:18 AM
|
|
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.
|
|
Description
|
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. |
Show » |
| Repository |
Revision |
Date |
User |
Message |
| ASF |
#416548 |
Fri Jun 23 02:56:11 UTC 2006 |
jgallacher |
As part of the improvments to FieldStorage, the Field class __init__ method
was changed in trunk (3.3-dev) and backported to branches/3.2.x. Although
the documentation states that the Field class is for internal use by
FieldStorage, some software applications create Field instances directly.
This change in the __init__ signature causes those applications to fail.
The code committed here is a work around that maintains forward compatibilty
with the FieldStorage improvements, while maintaining backward compatiblitly
with applications that may be using the Field class directly. (MODPYTHON-93)
|
| Files Changed |
MODIFY
/httpd/mod_python/branches/3.2.x/lib/python/mod_python/util.py
|
| Repository |
Revision |
Date |
User |
Message |
| ASF |
#417021 |
Sun Jun 25 14:40:44 UTC 2006 |
jgallacher |
Rolled back changes to Field and FieldStorage for MODPYTHON-93.
These changes were meant to improve FieldStorage efficiency, but
cause problems for applications such as Trac that treated
FieldStorage as a dictionary, or modified FieldStorage.list.
There is nothing in the documentation or source code stating that list
is private, or FieldStorage should be considered immutable, so these
applications were not wrong in doing so, and our changes should be
considered as unacceptable.
|
| Files Changed |
MODIFY
/httpd/mod_python/branches/3.2.x/Doc/appendixc.tex
MODIFY
/httpd/mod_python/branches/3.2.x/lib/python/mod_python/util.py
|
| Repository |
Revision |
Date |
User |
Message |
| ASF |
#468203 |
Fri Oct 27 00:18:08 UTC 2006 |
grahamd |
(MODPYTHON-93) Restored a level of backward compatibility for third party
packages which create instances of the Field class directly and insert them
direct into the list of form fields. This should mean that older versions
of Trac will still work.
|
| Files Changed |
MODIFY
/httpd/mod_python/trunk/lib/python/mod_python/util.py
|
|
Improvement
Closed
Minor
Improve util.FieldStorage efficiency
