Re: [Python-Dev] [RFC] urlparse - parse query facility

[O.R.Senthil Kumaran]

* Fred L. Drake, Jr. [EMAIL PROTECTED] [2007-06-13 22:42:21]:

 I see no reason to incorporate the URL splitting into the function; the 
 existing function signatures for cgi.parse_qs and cgi.parse_qsl are 
 sufficient.

Thanks for the comments, Fred. I understand, that having the signatures of
parse_qs and parse_qsl are sufficient in the urlparse module and invoking the
same from cgi module will be correct.

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).

http://deadbeefbabe.org/paste/5154

 It may be convenient to add methods to the urlparse.BaseResult class 
 providing 
 access to the parsed version of the query on the instance.
 

This is where, I spent a little bit time and I am unable to comeout
conclusively as how it can be done.

Someone in the list, please help me.

* parse_qs or parse_qsl will be invoked on the query component separately by
the user.
* 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.
* 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.


Thanks,
Senthil

-- 
O.R.Senthil Kumaran
http://uthcode.sarovar.org
___
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

Re: [Python-Dev] [RFC] urlparse - parse query facility

[Fred L. Drake, Jr.]

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).
 
  http://deadbeefbabe.org/paste/5154

Looks good.

   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 
(untested):

def parsedQuery(self, keep_blank_values=False, strict_parsing=False):
return parse_qs(
self.query,
keep_blank_values=keep_blank_values,
strict_parsing=strict_parsing)

def parsedQueryList(self, keep_blank_values=False, strict_parsing=False):
return parse_qsl(
self.query,
keep_blank_values=keep_blank_values,
strict_parsing=strict_parsing)

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

-- 
Fred L. Drake, Jr.   fdrake at acm.org
Chaos is the score upon which reality is written. --Henry Miller
___
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