Changes by A.M. Kuchling a...@amk.ca:
--
nosy: -akuchling
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1500504
___
___
Python-bugs-list mailing
Changes by Berker Peksag berker.pek...@gmail.com:
--
nosy: +berker.peksag
versions: +Python 3.5 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1500504
___
A.M. Kuchling added the comment:
Here's a slightly modified version of urischeme.py that can be run under Python
3 and compares its results with urllib.parse, printing out the mismatches.
The major differences seem to be 1) urischeme fills in the default port if it's
not explicitly provided,
Changes by Martin Panter vadmium...@gmail.com:
--
nosy: +vadmium
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1500504
___
___
Python-bugs-list
Changes by Łukasz Langa luk...@langa.pl:
--
nosy: +lukasz.langa
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1500504
___
___
Python-bugs-list
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
versions: +Python 3.4 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1500504
___
___
Éric Araujo mer...@netwok.org added the comment:
Sure, adding tests is a no-brainer.
Regarding the module, I’m a bit reluctant. I see value in providing low-level
building blocks (think OS calls) and high-level utilities for regular use, but
here it seems that urllib.parse and urischemes are
Nick Coghlan ncogh...@gmail.com added the comment:
Just to be clear, even *I* don't think adding urischemes as it stands is a
particularly great idea, and I wrote it. The only reason I haven't closed the
issue is because I'd like to see it mined for additional tests in test_urlparse
and
Éric Araujo mer...@netwok.org added the comment:
Is this still relevant? Can’t the improvements make it into urllib.parse?
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1500504
Nick Coghlan ncogh...@gmail.com added the comment:
I still like the higher level API concept, although I might not do it exactly
as presented here any more.
Independently of introducing a new parsing API, it would be worthwhile
extracting the parsing tests from the attached module to make
Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: +Python 3.2 -Python 2.7, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1500504
___
Nick Coghlan ncogh...@gmail.com added the comment:
accepted is a little too strong for the current status of this :)
I've removed the easy tag as well (making the case for this or something like
it in the standard library it going to involve a fair bit of effort - the
coding was actually the
Senthil Kumaran orsent...@gmail.com added the comment:
A new way for parsing URI. I have not reviewed it even after saying I would
like to, but having the dependency issue resolved, I think it is good to look
at it again, especially if it leads some helpful approaches to parsing IRI.
Changes by Senthil orsent...@gmail.com:
--
nosy: +orsenthil
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1500504
___
___
Python-bugs-list mailing
Nick Coghlan ncogh...@gmail.com added the comment:
The code itself is no longer the hard part here (hence the easy tag).
The problem is the fact that getting something like this into the
standard library is a tough sell on python-dev because it isn't really a
field tested module, but once
Daniel Diniz aja...@gmail.com added the comment:
ISTM that gathering the issues where this would help is a good start,
but I haven't had the time to do it yet.
--
dependencies: +URI parsing library
___
Python tracker rep...@bugs.python.org
Senthil orsent...@gmail.com added the comment:
I am willing to review this/work on it. But I wonder if this can be
categorized as easy task.
1) Integration to Standard Library will involve compatibility with
existing parsing, which will invariably involve certain tweaks (with
discussions/buy-in
Daniel Diniz aja...@gmail.com added the comment:
I'll collect open issues that would be solved by this.
--
components: +Library (Lib) -None
nosy: +ajaksu2
stage: - patch review
type: - feature request
versions: +Python 2.7, Python 3.1
___
Python
18 matches
Mail list logo