[Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
Guido van Rossum
guido at python.org
Wed Mar 16 04:34:13 CET 2011
More information about the Python-Dev mailing list
Wed Mar 16 04:34:13 CET 2011
- Previous message: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
- Next message: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Mar 15, 2011 at 7:58 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: > On Tue, Mar 15, 2011 at 7:14 PM, Senthil Kumaran <orsenthil at gmail.com> wrote: >> On Wed, Mar 16, 2011 at 7:01 AM, Nick Coghlan <ncoghlan at 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 3986, expect for the cases where those >> conflict with the previous RFCs. (IOW, backwards compatible). >> The tests can give you a good picture here. Do you mean, we should >> just do away with backwards compatibility? Or you had anything else >> specifically in mind? > > Backwards compatible with *what* though? > > 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 > don't provide a spec-conformant implementation, even via a flag or new > function. Can you be specific? What is different between those RFCs? -- --Guido van Rossum (python.org/~guido)
- Previous message: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
- Next message: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list