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
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
..]
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
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,
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
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.
