Jim Gallacher wrote:
> Max Bowsher wrote: 
> 
> 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.
 
> 
> 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.
>  
> 
> 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.

Attachment: signature.asc
This has been downloaded 0 time(s).

[ Post a follow-up to this message ]