[Python-Dev] [RFC] urlparse - parse query facility
Fred L. Drake, Jr.
fdrake at acm.org
Sat Jun 16 07:06:59 CEST 2007
On Saturday 16 June 2007, O.R.Senthil Kumaran wrote:
> The urlparse will cotain parse_qs and parse_qsl takes the query string
> (not url) and with optional arguments keep_blank_values and strict_parsing
> (same as cgi).
> > It may be convenient to add methods to the urlparse.BaseResult class
> > providing access to the parsed version of the query on the instance.
> * parse_qs or parse_qsl will be invoked on the query component separately
> by the user.
Yes; this doesn't change, really. Methods would still need to be invoked
separately, but the query string doesn't need to be passed in; it's part of
the data object.
> * If parsed query needs to be available at the instance as a convenience
> function, then we will have to assume the keep_blank_values and
> strict_parsing values.
If it were a property, yes, but I think a method on the result object makes
more sense because we don't want to assume values for these arguments.
> * Coding question: Without retyping the bunch of code again in the
> BaseResult, would is the possible to call parse_qs/parse_qsl function on
> self.query and provide the result? Basically, what would be a good of
> doing it.
That's what I was thinking. Just add something like this to BaseResult
def parsedQuery(self, keep_blank_values=False, strict_parsing=False):
def parsedQueryList(self, keep_blank_values=False, strict_parsing=False):
Whether there's a real win with this is unclear. I generally prefer having an
object that represents the URL and lets me get what I want from it, rather
than having to pass the bits around to separate parsing functions. The
result objects were added in 2.5, though, and I've no real idea how widely
they've been adopted.
Fred L. Drake, Jr. <fdrake at acm.org>
"Chaos is the score upon which reality is written." --Henry Miller
More information about the Python-Dev