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

Mike Brown mike at skew.org
Fri Jun 9 06:54:18 CEST 2006

John J Lee wrote:
> > http://python.org/sf/1500504
> [...]
> At first glance, looks good.  I hope to review it properly later.
> One point: I don't think there should be any mention of "URL" in the 
> module -- we should use "URI" everywhere (see my comments on Paul's 
> original version for a bit more on this).


Although you've added the test cases from 4Suite and credited me for them,
only a few of the test cases were invented by me.  I'd rather you credited
them to their original sources, as I did.

Also, I believe Graham Klyne has been adding some new cases to his Haskell
tools, but hasn't been updating the other spreadsheet and RDF files in which 
he publishes them in a more usable form. My tests only use what's in the 
spreadsheet, so I've only got 88 out of 99 "testRelative" cases from
So if you really want to be thorough, grab the missing cases from there.


It appears that Paul uploaded a new version of his library on June 3:
I'm unclear on the relationship between the two now. Are they both up for 


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

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.

More information about the Python-Dev mailing list