[Python-Dev] Some more comments re new uriparse module, patch 1462525

[Paul Jimenez]

On Thursday, Jun 8, 2006, Mike Brown writes:
>
>It appears that Paul uploaded a new version of his library on June 3:
>http://python.org/sf/1462525
>I'm unclear on the relationship between the two now. Are they both up for 
>consideration?

That version was in response to comments from JJ Lee.  Email also went to pydev
(archived at http://mail.python.org/pipermail/python-dev/2006-June/065583.html)
about it.

>One thing I forgot to mention in private email is that I'm concerned that the
>inclusion of URI reference resolution functionality has exceeded the scope of
>this 'urischemes' module that purports to be for 'extensible URI parsing'.  It
>is becoming a scheme-aware and general-purpose syntactic processing library
>for URIs, and should be characterized as such in its name as well as in its
>documentation. 

...which is why i called it 'uriparse'. 

>Even without a new name and more accurately documented scope, people are going
>to see no reason not to add the rest of STD 66's functionality to it
>(percent-encoding, normalization for testing equivalence, syntax
>validation...). As you can see in Ft.Lib.Uri, the latter two are not at all
>hard to implement, especially if you use regular expressions. These all fall 
>under syntactic operations on URIs, just like reference-resolution.
>
>Percent-encoding gets very hairy with its API details due to application-level
>uses that don't jive with STD 66 (e.g. the fuzzy specs and convoluted history
>governing application/x-www-form-urlencoded), the nuances of character
>encoding and Python string types, and widely varying expectations of users.

...all of which I consider scope creep. If someone else wants to add
it, more power to them; I wrote this code to fix the deficiencies in
the existing urlparse library, not to be an all-singing all-dancing
STD 66 module. In fact, I don't care whether it's my code or someone
else's that goes into the library - I just want something better than
the existing urlparse library to go in, because the existing stuff has
been acknowledged as insufficient. I've even provided working code with
modifications to fix comments and criticism I've received. If you or
someone else want to extend what I've done to add features or other
functionality, that would be fine with me. If you want to rewrite the
entire thing in a different vein (as Nick Coghlan as done), be my guest.
I'm not married to my code or API or anything but getting an improved
library into the stdlib. To that end, if it's decided to go with my
code, I'll happily put in the work to bring it up to python community
standards. Additional functionality will have to come from someone else
though, as I'm not willing to try and scratch an itch I don't have - and
I've already got a day job.

  --pj