quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Looijmans <nlv11...@natlab.research.philips.com>
Subject Re: mod_python 3.2.9-rc2 available for testing
Date Tue, 27 Jun 2006 13:07:24 GMT
Having written most of the issue "93" code, here's my opinion:

> * How much non-compatibility is acceptable in a patch release?

None.
Though it hurts my personal feelings that my patch did manage to break 
something (who imagined anyone trying to hack data into the FS object?), 
we cannot break other people's software with a mere patch.

I don't have a clue what the "trac" software is, but I imagine that even 
for this particular piece of software, I may be able to come up with 
some form of emulation (e.g. using __setattr__ hooks) that still keeps 
it working with the patch. The question is of course, where does it stop?

Note that the "old" code still contains a bug that the patch solves. The 
problem is that the old code does not work correctly if the objects 
created in a make_file callback are not real files created with file().

> * 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)



Mime
View raw message