Documentation for done attribute of FieldStorage class

[bkline]

BPO	1172
Nosy	@freddrake, @bkline
Files	cgi.rst.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2007-09-18.23:40:00.547>
created_at = <Date 2007-09-17.19:19:47.010>
labels = ['type-feature', 'docs']
title = 'Documentation for done attribute of FieldStorage class'
updated_at = <Date 2007-09-18.23:40:00.546>
user = 'https://github.com/bkline'

bugs.python.org fields:

activity = <Date 2007-09-18.23:40:00.546>
actor = 'jafo'
assignee = 'jafo'
closed = True
closed_date = <Date 2007-09-18.23:40:00.547>
closer = 'jafo'
components = ['Documentation']
creation = <Date 2007-09-17.19:19:47.010>
creator = 'bkline'
dependencies = []
files = ['8445']
hgrepos = []
issue_num = 1172
keywords = ['patch']
message_count = 6.0
messages = ['55975', '55997', '56001', '56004', '56005', '56018']
nosy_count = 3.0
nosy_names = ['fdrake', 'jafo', 'bkline']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1172'
versions = ['Python 2.6', 'Python 2.5', 'Python 3.0']

[bkline]

I have attached a patch which adds partial documentation for the done
attribute of the cgi.FieldStorage class. This addition is needed in
order to make it safe to rely on the current behavior of the class,
which sets this attribute to the value -1 when an uploaded file from a
CGI form does not arrive intact.

If I have sufficient free time to do so at some point in the future, I
would like to submit a more extensive modification for the module's
documentation, using a format which matches that used for most of the
other modules (that is, including documentation of all of the methods
and attributes intended for public use), and I'd be inclined to modify
the cgi.py module itself, to use a less opaque approach for conveying
the failure than the 'done' attribute. I'd want some indication that
there was a reasonable chance that if I were to invest the work on this
improvement the results would actually be used (I see my latest patch
for the module has been languishing in the 'ignored' pile for over a
year). If anyone else is doing some overhaul work in this area, please
speak up so we don't end up with duplication of effort.

I would think that this module would be one of the most commonly used in
the entire Python library, and would thus warrant careful maintenance
(including addressing all of the "XXX let's fix this ..." comments.

Cheers!

[jafo]

Patch looks good to me. Fred?

Comments on "should I do more fixes": Just straight documentation
changes are, in my experience, fairly likely to be processed quickly.
Changes to the code may take quite a lot more discussion. Smaller,
individual patches are likely to be taken much more than large mega
patches that change many things.

So, my recommendation would be to do individual efforts: Fix the current
documentation, fix "XXX fix me" parts, do enhancements.

I understand where you're coming from, I spent a full day implementing
string.rsplit() including documentation, only to have it languish for
around a year before other people re-opening the rejected submission
finally got it accepted. However, python definitely benefits from the
attention. Sometimes things do get dropped, because of other
commitments from the maintainers.

Assign your issue that has been ignored to me and I'll take a look at it.

[freddrake]

Looks good to me too. This should be committed.

[bkline]

Thanks for the very quick follow-up. I may be shooting myself in the
foot here, but Sean's encouragement about getting patches to the actual
code lead me to wonder if it might be better to go straight for the
optimal solution here. As I implied in my original message for this
issue, there are approaches for exposing the ability to detect failure
which would be more straightforward than testing for field.done == -1.
A step in the right direction might be an attribute named something like
'incomplete' (True|False). Or perhaps an access method? Based on my
more recent experience with getting code patches accepted, I had settled
on just documenting the existing code more fully as a minimal solution,
but if Sean's more optimistic advice is justified, I'd be happy to wait
a little longer for a cleaner solution (and to pitch in for the work to
create it, if that's appropriate). I know I have more than one bit of
Python code I wrote years ago for situations similar to this where if I
had to do it over again I would have thrown an exception, and maybe
that's the right thing to do here, with an optional argument to the
constructor which suppresses the exception. Perhaps Guido might want to
weigh in with his own preferences (this is his code, and he's still
listed as the current maintainer of the module). But I'd rather have
the documentation patch for the existing code than nothing at all.

Cheers,
Bob

[bkline]

Sean Reifschneider wrote:

Assign your issue that has been ignored to me and I'll take a
look at it.

I tried, but it doesn't look like I have sufficient permission to change
the assignment. It's

http://bugs.python.org/issue1541463

Thanks!

[jafo]

Committed in trunk revision 58199
Committed in 25-maint revision 58200
Committed in py3k revision 58201