Mike Looijmans wrote:
>>>> * How are applications supposed to perform write operations on a
>>>> FieldStorage, in 3.3 and the future?
>>>
>>> Since we claim that FieldStorage behaves like a dictionary, the obvious
>>> syntax would be:
>>>
>>> form['mykey'] = 'value'
>>>
>>> This would require a __setitem__ method which should look something like
>>> this (with some extra code to handle lists):
>>>
>>> def __setitem__(self, key, value):
>>> if self.dictionary is None:
>>> # Create self.dictionary as in __getitem__
>>> self.dictionary[key] = StringField(value)
>>
>>
>>
>> Trac also appends to the FieldStorage list attribute, which complicates
>> things a little further.
>>
>> The '93' code also adds the add_field() method. Although this is not
>> documented, there is nothing to indicate that it is a private method
>> either. Calling add_field on a FieldStorage instance will not likely
>> give the results a user expects, so we need to give some attention to
>> that as well.
>
> I initially intended add_field as a callback routine, which was later on
> replaced with the callback. The method is not really neccesary, but
> quite convenient when subclassing. All the processing takes place in
> __init__ which makes it impossible to just replace the method at
> runtime, which I had in mind at first.
>
> I think we should support the dictionary syntax, e.g.
>
> form['key']='value'
> assert form['key'] == 'value'
>
> The dict syntax will replace all 'key' fields with the new value. The
> add_field method can be reworked to act as one would expect, e.g.:
>
> assert form['key'] == 'value'
> form.add_field('key', 'value2')
> assert form['key'] == ['value','value2']
> form.add_field('key', 'value1')
> assert form['key'] == ['value','value2','value1']
>
> Maybe we can come up with a better name than add_field (append?) as well.
It seems to me that FieldStorage is a kind of ordered dictionary
