Brian.Bird at securetrading.com
Fri Oct 27 04:12:08 EDT 2006
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?