[Python-Dev] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)

[Tino Wildenhain]

Hi,

Senthil Kumaran wrote:
> On Mon, Apr 13, 2009 at 5:31 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>> Say you are filtering or sorting data based on some URL parameters. If the user
>> wants to remove one of those filters, you have to remove the corresponding query
>> parameter.
> 
> This is a use-case and possibly a hypothetical one which a programmer
> might do under special situations.
> There are lots of such use cases for which urllib.parse or urlparse
> has been used for.
> 
> But my thoughts with this proposal is do we have a good RFC
> specfications to implementing this?
> If not and if we go by just go by the practical needs, then eventually
> we will end up with bugs or feature requests in this which will take a
> lot of discussions and time to get fixed.
> 
> Someone pointed out to read HTML 5.0 spec instead of RFC for this
> request. I am yet to do that, but my opinion with respect to additions
> to url* module is - backing of RFCs would be the best way to go and
> maintain.


I'd rather like to see an ordered dict like object returned by urlparse 
for parameters this would make extra methods superfluous.

Also note that you might need to specify the encoding
of the data somewhere (most of the times its utf-8 but it depends on the
encoding used in the form page).

A nice add-on would actually be a template form object which holds all
the expected items and their type (and if optional or not) with little
wrappers for common types (int, float, string, list, ...) which
generate nice execeptions when used somewhere and not filled/no default
or actually wrong data for a type.

Otoh, this might get a bit too much in direction of a web app framework.

Regards
Tino