Issue #141 resolved

use cgi.parse_qs()

Anonymous created an issue

Per this [ thread], I propose using cgi.parse_qs() rather than re-implementing it in

Reported by

Comments (8)

  1. Anonymous

    It occurs to me that cgi.parse_qs() introduces a potential incompatibility with the parsing mechanism currently implemented. cgi.parse_qs converts variable to a list of length 0, 1, or more.

    I hold a preference for this way of parsing. It makes code to handle input more robust and less obfuscated by conditionals that test if a value is a singleton string or a list of strings... it's simply always a list.

    What do people think?

  2. Anonymous

    As I found out (Ticket #142), you need to add a patch to the test suite, as well, specifically test/

  3. Anonymous

    Ah, thanks for the work fumanchu.

    I'm actually in favor of modifying the behavior (or, at least making it a global switch in the server startup) so that it is like cgi.parse_qs(). It makes more sense to me that every variable's value is always a list, either of length 0, 1, or more. Rather than having extra code to test if it IS a list first.

    This favoring seems to have been echoed by at least one other -devel'er (alankila), at:

    I'm also marking this as an "ehancement" rather than "normal". That seems to describe it better.


  4. Anonymous

    It makes more sense to me that every variable's value is always a list

    Perhaps, but that's an issue separate from this patch/ticket. ;) I think it's better to stick with the existing spec for now. We can get this accepted now and hash out the always-a-list option on the mailing list(s) later.

  5. Log in to comment