Nick wrote:
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.
Oops. Brain fart. When I read the code I s/__getattr__/__getitem__/g.
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).
You are correct, there is no problem. It works as advertised. Operator
error... whoot, whoot, whoot. :)
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.
Just curious. How do you use it?
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?
Exactly. I guess my question would be "is there any reason to *not*
refactor our code"?
Jim
