Jim Gallacher wrote:
For starters, most of the methods such as keys, has_key and so on will
raise an exception since you don't create the dictionary until after one
of the fields is accessed via __getitem__. Also, has_key will return
false for a field that actually exists if that field has not yet been
accessed.
Since __getitem__ refers to self.dictionary, it would get created at that
point. I don't think that's an issue.
def hander(req):
form = FieldStorage(req)
# this will raise an exception
keys = form.keys()
I still think the correct place to create the index dictionary is in the
__init__ phase. Using the dictionary-on-demand idea only improves
performance on the second access to a form field. For the first access
you are still iterating through the whole list for each field name.
Isn't that what "on-demand" means? If you never use the dictionary, you'll
never have to wait for it to be created. This is at worst no worse than
what is there now (actually it's better the way he's coded it).
I personally think any performance degradation resulting from creating
the dictionary in __init__ will be small compared to the overall
improvement we'll get for accessing the fields. I would advocate
creating the dictionary in the add_field() method.
Depends on the size of the form, but I can see a performance hit for people
(like me) who never use FieldStorage as a dictionary.
Since we are messing with these classes anyway, is there any reason we
are not using new-style classes, which is to say subclassing object?
Isn't that the default in 2.3+, which is what mod_python now requires?
Nick
