Senthil Kumaran orsent...@gmail.com added the comment:
Committed the tests in the r80908, r80909, r80910 and r80911.
The backward incompatible test cases, as in whose parsing requirements have
changed since the previous RFC has been commented out. There were 4 abnormal
scenarios and one strict
Paul Jimenez p...@place.org added the comment:
That sounds great - at least something useful will come out of this, even if
it's just more tests for urlparse :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1462525
Changes by R. David Murray rdmur...@bitdance.com:
--
resolution: - out of date
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1462525
___
___
Senthil Kumaran orsent...@gmail.com added the comment:
Should we close this as out-of-date? I was inclined to see it as fixed as
urlparse has gone changes in direction as suggested by the issue.
Sorry Paul, for no response.
Regarding this issue, I plan to use the testcases provided in the
Paul Jimenez p...@place.org added the comment:
Since no one else has commented on this in over a year, and the new (2.6+) code
works fine, I'll just close this to help clean things up.
--
status: open - closed
___
Python tracker
Paul Jimenez p...@place.org added the comment:
Senthil wrote:
Senthil orsent...@gmail.com added the comment:
Hello Paul,
Have you beeing keeping track of urlparse changes in Python2.6?
No - do you have pointers to the particular changes you're
referring to? I've done a bit of trying
Changes by Daniel Diniz aja...@gmail.com:
--
stage: - test needed
type: - feature request
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1462525
___
Senthil [EMAIL PROTECTED] added the comment:
Hello Paul,
Have you beeing keeping track of urlparse changes in Python2.6? I
anaylzed your patch and read through the RFC3986 and have the
following comments:
1) The usage of this module is very diffirent from the current
urlparse module's
Facundo Batista [EMAIL PROTECTED] added the comment:
Senthil, we should incorporate the tests from RFC 3986 to the test
suite, what do you think?
Coul we integrate the effort from Paul Jimenez and the current urlparse
and achieve a RFC compliant library? Should we handle this compliance in
this
Changes by vila:
--
nosy: +vila
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1462525
_
___
Python-bugs-list mailing list
Unsubscribe:
vincent kraeutler added the comment:
In the meantime, I have found a very nice parser combinator library for
Python (pyparse) and have implemented a validating parser for RFC 3986
URI's by more or less simply converting the complete ABNF grammar found
in the RFC. Obviously, this will never make
vincent kraeutler added the comment:
Some more notes.
a) RFC3986 explicitly states that the presented regex (which you use)
is the regular expression for breaking-down a *well-formed* URI
reference into its components. (Emphasis added). I am not sure this
is a particularly good starting
vincent kraeutler added the comment:
Quite like urlparse, uriparse does not fail on input which does not
represent valid URI's. At least not early or reliably enough.
Specifically, I noticed that urisplit does not fail on input strings
with a missing scheme, such as foo.com/bar.
I see no
Isaac Morland added the comment:
This is probably overkill, but I've created a Python script (attached)
that runs all the tests given in Section 5.4 of RFC 3986. It reports
the following:
baseurl=http://a/b/c/d;p?q
failed for ?y: got http://a/b/c/?y, expected http://a/b/c/d;p?y
failed for
Changes by Skip Montanaro:
--
nosy: +skip.montanaro
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1462525
_
___
Python-bugs-list mailing list
Unsubscribe:
15 matches
Mail list logo
