[mod_python] util.FieldStorage

Well, in my case, the keys I want to set on the FieldStorage are
guaranteed not to already exist, so either way would be fine. However,
reading your email, FWIW it seems to make sense to me to be additive.

Perhaps if the documentation on util.FieldStorage is updated to reflect
this it would be fine. The only reason this 'problem' came about for me
was because I read the docs saying it works like a dictionary (except
for a few extra methods) and didn't stop to consider your points.

Similarly in my case I know the key I want to delete will only contain
one value, but I would probably expect it to delete all values
associated with a key if there was more than one.

Brian

> The issue with __setitem__() is whether it should be additive or
whether
> it
> should replace. The current add_field() member in 3.3 is additive.
That
> is, if
> a value for that key is already there, it adds an extra value against
the
> key
> rather than replacing any existing value. In Trac < 0.10.0 from memory
> they
> provided their own __setitem__() in a derived version of the class
which
> effectively did what add_field() did, ie., it was additive, which
isn't
> what
> many would expect of a dictionary. For __delitem__() only choice is
too
> delete all values associated with a key, not way to delete one value
> although
> one has to question why you might anyway. For setdefault(), second
> argument
> to get() achieves same outcome.
> 
> The main question then is how would people expect __setitem__() to
> behave?