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? Max.
signature.asc
Description: OpenPGP digital signature
