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 work just fine >> > with the older RFC semantics. > > Yes. We can have API which strictly confirms to latest RFC by > definition, but the problem is there is code out there which 'expects' > the parsing behavior remain unchanged so that their existing code does > not break. And with parsing behavior unchanged means conforming to > older RFC parsing rules. > > The solution seems to be extra function or an flag in the urlparse > method which will exhibit the more latest behavior. > > Guido wrote: > >> So would having two different API functions, one legacy and one >> conforming, be a problem? Ideally the conforming API's name would not >> be something lame like urllib2 but something timeless. :-) > > :-) Should blame Jeremy for that name!. But urllib2 is long replaced > by urllib.parse, urllib.request and urllib.response. Considering how > you remember urllib2, I think it's name has stood the test of time.
It stood out like a sore thumb. :-) > 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 explain my rule of thumb against flag arguments whose values are nearly always constants.) -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
