quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <...@jgassociates.ca>
Subject Re: mod_python 3.2.9-rc2 available for testing
Date Tue, 27 Jun 2006 16:43:29 GMT
Mike Looijmans wrote:
> 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 think this surprised many of us, as no one on the list seems to have
thought of that use case. Trac subclasses FieldStorage to get behaviour
more in line with cgi.py. We don't have any prohibitions on subclassing,
so although we didn't foresee this usage I think it is still legitimate.

> 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?

Trac is bugtracker / wiki that seems to be getting some traction. ;)

> 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().

So do you think we can release 3.2.9 with the old 3.2.8 code, or should
this block the release until we have a correct fix? I'm hoping we can do
a 3.3 release in October or November, FYI.

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


View raw message