I submitted patch 1462525 awhile back to
solve the problem described even longer ago in
http://mail.python.org/pipermail/python-dev/2005-November/058301.html
and I'm wondering what my appropriate next steps are. Honestly, I don't
care if you take my patch or someone else's proposed solution, but I
Announcing uriparse.py, submitted for inclusion in the standard library.
Patch request 1462525.
Per the original discussion at
http://mail.python.org/pipermail/python-dev/2005-November/058301.html
I'm submitting a library meant to deprecate the
existing urlparse library. Questions and comments wel
http://sourceforge.net/tracker/index.php?func=detail&aid=1462525&group_id=5470&atid=305470
This is just a note to ask when the best time to try and get this in is
- I've seen other new/changed libs going in for 2.5 and wanted to make
sure this didn't fall off the radar. If now's the wrong time,
..]
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
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. Ema
It is my assertion that urlparse is currently broken. Specifically, I
think that urlparse breaks an abstraction boundary with ill effect.
In writing a mailclient, I wished to allow my users to specify their
imap server as a url, such as 'imap://user:[EMAIL PROTECTED]:port/'. Which
worked fine.
