|
Graham Dumpleton
grahamd at dscpl.com.au
Thu Oct 26 07:48:03 EDT 2006
Yes, but how dictionary like is the issue that I don't see anyone giving
an answer for. Ie., out of:
>>> dir({})
['__class__', '__cmp__', '__contains__', '__delattr__',
'__delitem__', '__doc__', '__eq__', '__ge__', '__getattribute__',
'__getitem__', '__gt__', '__hash__', '__init__', '__iter__',
'__le__', '__len__', '__lt__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__setitem__', '__str__',
'clear', 'copy', 'fromkeys', 'get', 'has_key', 'items', 'iteritems',
'iterkeys', 'itervalues', 'keys', 'pop', 'popitem', 'setdefault',
'update', 'values']
what do you expect to be provided and work? Not all of them make
sense. Knowing which you think should work would be helpful.
I'd probably hold off trying to work out any patches yourself. The more
I look at FieldStorage the less I understand why some of the changes
were made. I'm not talking about how a dictionary based index was
added, but more how some of the code was shifted around when it
probably didn't need to, with the result being that the code then became
incompatible with versions of Trac which were out at the time. It would
not have been that hard to maintain compatibility with Trac and still
get
the desired gains they were after. I can see myself therefore doing a
bit
or reorganisation of the code to fix the identified issue, but also
reinstate
Trac compatibility.
Graham
On 26/10/2006, at 9:32 PM, Brian Bird wrote:
> The benefit of being more dictionary-like is just convenience. As
> util.FieldStorage doesn't have all the dictionary methods then I
> usually
> just convert it to a real dictionary.
>
> However, I'd like to also keep the getfirst and getlist methods, which
> would mean writing my own class to inherit from dict and converting
> between them. I can't easily inherit util.FieldStorage because all my
> code has standalone unittests which can't import _apache
>
> It's not the end of the world if util.FieldStorage isn't updated,
> but it
> would make my life a lot simpler ;-) I may try and have a go at
> updating
> it - is there any documentation on the best way to provide
> patches/unittests for ModPython?
>
> Brian
>
>
>> -----Original Message-----
>> From: Graham Dumpleton [mailto:grahamd at dscpl.com.au]
>> Sent: 26 October 2006 11:12
>> To: Brian Bird
>> Cc: mod_python at modpython.org 'mod_python at modpython.org'
>> Subject: Re: [mod_python] util.FieldStorage
>>
>> Yes, FieldStorage in 3.3 is broken in as much as add_field() if
>> called
>> after the first time that the 'dictionary' attribute is accessed in
>> some way,
>> does not result in that value ending up in the dictionary. Thus it is
>> not
>> visible to __getitem__(), has_key() etc.
>>
>> Something else to fix. :-(
>>
>> Graham
>>
>> On 26/10/2006, at 7:56 PM, Graham Dumpleton wrote:
>>
>>> The util.FieldStorage implementation in mod_python 3.3 is quite a
> bit
>>> different to what is used in older versions of mod_python and which
>>> you based your changes upon. Thus your changes are not compatible
>>> with the new code base.
>>>
>>> Some have talked about making the new implementation of the
>>> FieldStorage class more dictionary like than it is, but no one has
>>> stepped up to provide any changes.
>>>
>>> To be honest I haven't actually looked into how FieldStorage is
>>> implemented as someone outside of the core developers provided
>>> the updated code and it was integrated by someone other than
>>> myself. Looking at the code now, I actually think it might be a bit
>>> broken. I'll have to do some playing with the code.
>>>
>>> BTW, what benefits do you think you get if it is more dictionary
> like?
>>> I am not sure I understand the reason for making such changes in
>>> the first place.
>>>
>>> Graham
>>>
>>> On 26/10/2006, at 7:14 PM, Brian Bird wrote:
>>>
>>>> Is there anything in the works to make util.FieldStorage act more
>>>> like a real dictionary? Specifically, it doesn't support the
>>>> __setitem__, __delitem__ methods. Since the documentation states
>>>> "it can be treated like a dictionary" I was surprised to find
>>>> these methods missing.
>>>>
>>>>
>>>>
>>>> I know it's easy to change it to a real dictionary to get these
>>>> methods, but then you lose the (very useful) getlist() method. At
>>>> first glance it doesn't look like much work to add the extra
>>>> methods (but I haven't looked at how it may affect values which
>>>> aren't StringField's).
>>>>
>>>>
>>>>
>>>> I've just looked in the latest subversion and found that the items
>>>> () method is now in util.FieldStorage, as well as a method
>>>> add_field() which looks suspiciously like __setitem__ should, but
>>>> no sign of a __delitem__. However, there now seems to be a
>>>> self.dictionary object which could be useful - perhaps all
>>>> unrecognised methods should be passed onto self.dictionary in the
>>>> __getattr__ instead of raising an AttributeError?
>>>>
>>>>
>>>>
>>>> I've put below what I thought needed adding to the
>>>> util.FieldStorage class before I noticed self.dictionary in case
>>>> it's any help.
>>>>
>>>>
>>>>
>>>> ### Disclaimer - completely untested! J ###
>>>>
>>>>
>>>>
>>>> def __setitem__(self, key, value):
>>>>
>>>> self.list.append(util.Field(key, cStringIO.StringIO(key),
>>>> "text/plain", {}, None, {}))
>>>>
>>>>
>>>>
>>>> def __delitem__(self, key):
>>>>
>>>> for item in self.list:
>>>>
>>>> if item.name == key:
>>>>
>>>> self.list.remove(item)
>>>>
>>>>
>>>>
>>>> def items(self):
>>>>
>>>> result = []
>>>>
>>>> for key in self.keys():
>>>>
>>>> result.append((key, self[key]))
>>>>
>>>> return result
>>>>
>>>>
>>>>
>>>> def update(self, d):
>>>>
>>>> for k in d.keys():
>>>>
>>>> self[k] = d[k]
>>>
>>> _______________________________________________
>>> Mod_python mailing list
>>> Mod_python at modpython.org
>>> http://mailman.modpython.org/mailman/listinfo/mod_python
>
>
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python
|