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

[Nick Coghlan]

Paul Jimenez wrote:
> On Friday, Jun 2, 2006, John J Lee writes:
>> [Not sure whether this kind of thing is best posted as tracker comments 
>> (but then the tracker gets terribly long and is mailed out every time a 
>> change happens) or posted here.  Feel free to tell me I'm posting in the 
>> wrong place...]
> 
> I think this is a fine place - more googleable, still archived, etc.
> 
>> Some comments on this patch (a new module, submitted by Paul Jimenez, 
>> implementing the rules set out in RFC 3986 for URI parsing, joining URI 
>> references with a base URI etc.)
>>
>> http://python.org/sf/1462525
> 
> Note that like many opensource authors, I wrote this to 'scratch an
> itch' that I had... and am submitting it in hopes of saving someone else
> somewhere some essentially identical work. I'm not married to it; I just
> want something *like* it to end up in the stdlib so that I can use it.

I started to write a reply to this with some comments on the API (including 
the internal subclassing API), but ended up with so many different suggestions 
it was easier to just post a variant of the module. I called it "urischemes" 
and posted it on SF:

http://python.org/sf/1500504

It takes more advantage of the strict hierarchy defined in RFC 3986 by always 
treating parsed URI's as 5-tuples, and the authority component as a 4-tuple. A 
parser is allowed to return any object it likes for the path, query or 
fragment components, so long as invoked str() on the result gives an 
appropriate string for use by make_uri.

Additionally, since the semantics won't be the same as urlparse anyway, I 
haven't been as worried about keeping the APIs identical (although they're 
still similar).

In various places, it also makes more use of keyword arguments and 
dictionaries to specify defaults values, rather than relying on tuples padded 
with lots of Nones.

There's more in the tracker item about the API and implementation differences. 
They're all about improving maintainability and extensibility rather than 
providing any additional functionality.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org