|
Brian Bird
Brian.Bird at securetrading.com
Thu Oct 26 08:14:18 EDT 2006
Hmm, good question. The term "dictionary-like" doesn't actually have a
definitive meaning does it?
In my case, the methods I was expecting to find were:
__getitem__, __setitem__, __delitem__, get, has_key, items, keys,
setdefault, update, values
However, if util.FieldStorage is meant to be "treated like a dictionary"
then I can imagine when someone will expect all the other methods too.
This makes me think that if FieldStorage is going to contain some kind
of internal dictionary to store the actual data, perhaps these other
dict methods should be called directly on it: ie.
def __getattr__(self, attr):
return getattr(self.dictionary, attr)
or possibly it could be re-written to inherit from dict directly?
If this is going to become a pain though, I'll live with the
inconvenience in my code of swapping between objects when necessary :-)
Brian
> -----Original Message-----
> From: Graham Dumpleton [mailto:grahamd at dscpl.com.au]
> Sent: 26 October 2006 12:48
> To: Brian Bird
> Cc: mod_python at modpython.org
> Subject: Re: [mod_python] util.FieldStorage
>
> 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
|