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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
