On Fri, Mar 18, 2011 at 1:38 PM, Guido van Rossum gu...@python.org wrote:
But seriously, I think an additional function or additional flag in the
current functions/method in the parse module is sufficient than going
for another module.
I vote for a new function, not a flag. (Others can
On Fri, Mar 18, 2011 at 5:32 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Mar 18, 2011 at 1:38 PM, Guido van Rossum gu...@python.org wrote:
But seriously, I think an additional function or additional flag in the
current functions/method in the parse module is sufficient than going
for
On Mar 18, 2011, at 8:41 PM, Guido van Rossum wrote:
Really. Do they still call them URIs? :-)
Well, by RFC 398*7* they're calling them IRIs instead. 'irilib', perhaps? ;-)
___
Python-Dev mailing list
Python-Dev@python.org
On Fri, Mar 18, 2011 at 08:57:42PM -0400, Glyph Lefkowitz wrote:
Well, by RFC 398*7* they're calling them IRIs instead. 'irilib', perhaps? ;-)
Yes, and it involves huge lot of unicode character handling /parsing
rules in Resource Indentifiers. 'irilib' sounds like a good plan.
--
Senthil
On Wed, Mar 16, 2011 at 5:02 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Mar 15, 2011 at 11:34 PM, Guido van Rossum gu...@python.org wrote:
Can you be specific? What is different between those RFCs?
I finally got around to trying to backport some of the additional
urljoin tests from
Nick Coghlan wrote:
The problem is that it is quite a lot of work to get fully general URI
parsing to work correctly, but the overlap with legacy URL parsing is
large enough that many (most?) use cases in practice work just fine
with the older RFC semantics.
Yes. We can have API which
On Thu, Mar 17, 2011 at 8:19 PM, Senthil Kumaran orsent...@gmail.com wrote:
Nick Coghlan wrote:
The problem is that it is quite a lot of work to get fully general URI
parsing to work correctly, but the overlap with legacy URL parsing is
large enough that many (most?) use cases in practice
On Tue, Mar 15, 2011 at 11:34 PM, Guido van Rossum gu...@python.org wrote:
Can you be specific? What is different between those RFCs?
I finally got around to trying to backport some of the additional
urljoin tests from http://bugs.python.org/issue1500504 (specifically,
the additional ones Mike
On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
With RFC 3986 passing its 6th birthday, and with it being well past
its 7th by the time 3.3 comes out, can we finally switch to supporting
the current semantics rather than the obsolete behaviour?
We do infact, support RFC
On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran orsent...@gmail.com wrote:
On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
With RFC 3986 passing its 6th birthday, and with it being well past
its 7th by the time 3.3 comes out, can we finally switch to supporting
the
On Tue, Mar 15, 2011 at 7:58 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran orsent...@gmail.com wrote:
On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
With RFC 3986 passing its 6th birthday, and with it being well past
its
Nick Coghlan wrote:
Backwards compatible with *what* though?
I meant the parsing 'behavior'.
For the decimal module, we treat deviations from spec as bug fixes and
update accordingly, even if this changes behaviour.
For URL parsing, the spec has changed (6 years ago!), but we still
On Wed, Mar 16, 2011 at 12:03 AM, Senthil Kumaran orsent...@gmail.com wrote:
A new function, which can given this behavior is also a good idea.
I'm strongly in favor of this approach. I know we've been bitten by
changes made in the past, and have had to introduce Python-version
specific
13 matches
Mail list logo
