quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Bowsher <ma...@ukf.net>
Subject Re: 3.2.9-rc2 FieldStorage Problems (was Re: mod_python 3.2.9-rc2 available for testing)
Date Fri, 23 Jun 2006 19:46:19 GMT
Jim Gallacher wrote:
> Max Bowsher wrote:
>> The root of the problem is that Trac wants to be able to add extra
>> fields to a FieldStorage itself, and has been jumping through all sorts
>> of crazy hoops in the internals of FieldStorage to make this happen.
> Which suggests bad design in either Trac or FieldStorage. Personally I
> think FieldStorage is an ugly piece of work so we'll let the blame fall
> there for now. ;)
> Such meddling in FieldStorage makes me nervous. I'd rather revert all of
> the changes corresponding to MODPYTHON-93 (Improve util.FieldStorage
> efficiency) and proceed with a 3.2.9 release. The old code works even if
> it is not the most elegant.

Excellent - 3.2.9 is valuable for all sorts of other reasons, not least
apache 2.2 and bash 3.1 compatibility, and then non-trivial FieldStorage
tidying can happen in mod_python 3.3.

>> So, I guess the two questions to answer now are:
>> * How much non-compatibility is acceptable in a patch release?
> I'd say none, unless the non-compatibility is absolutely essential to
> fix some critical bug. You should be able to just drop in a patch
> release and carry on without any fuss. The problems we've created for
> Trac here are unacceptable.
>> * How are applications supposed to perform write operations on a
>> FieldStorage, in 3.3 and the future?
> Personally I never considered writing to FieldStorage. I always thought
> of it as a read-only representation of a submitted form, but then that's
> just my mental map.

It's a pretty uncommon usage - it surprised me when I saw it in Trac.
Trac is using it to bundle additional request information gathered from
sources other than the form itself - it makes me suspect that someone in
the past thought "hey, we have this dictionary-like thing we are passing
around already - wouldn't it be nice if we could shove extra things in
it, rather than passing around another object too?", and then proceeded
to hack things so it was possible.

> The docs state "The FieldStorage class has a mapping object interface,
> i.e. it can be treated like a dictionary". There is no mention that
> FieldStorage is immutable, and I certainly think from the description
> that most people would assume it could be used like a dictionary. Also
> as Max points out there are no implied restrictions on the list
> attribute, so an application should be free to modify it if desired.
> Since a 3.3 release is at least a few months away, I think we can take
> our time and give this some careful consideration. Maybe the best plan
> is to leave FieldStorage as-is for legacy applications and start fresh
> on a brand new FieldStorageNG class,  without worrying about backwards
> compatibility?

There are projects which allow compatibility breakage only on major
(i.e. 3.x -> 4.x) version bumps [e.g. APR, Subversion] and those which
allow it on minor (i.e. 3.2.x -> 3.3.x) version bumps [e.g. Apache
HTTPD, Berkeley DB]. Into which category does mod_python place itself?


View raw message