The location of the url-handling functions are
distributed among several modules, and it would be good
to consolidate them to make them easier to find.

The urlparse.urlparse() function splits an url into its
relative pieces. However, it does not parse out the
query string into a dictionary --- that role is played
by cgi.parse_qs(). And to convert a dictionary back to
a query string, the programmer needs to know that that
function is in urllib.urlencode.

It would be nice to have cgi.parse_qs() and
urllib.urlencode() in a unified place, within in the
urlparse module if appropriate. This will help reduce
the amount of hunting-and-pecking that beginners do
when they're trying to deal with URLs.

See:

http://mail.python.org/pipermail/tutor/2002-August/016823.html

for more information.

Thanks!

Logged In: YES
user_id=357491

This is a problem. Should a wrapper in urlparse for cgi.parse_qs but created
or should it just be documented that to parse a query string you should use
cgi.parse_qs?

I know that Senthil has been working on consolidating url related
functionalities so I am adding him to the list.

parse_qs and parse_qsl moved to urlparse with this patch.
I dont think urlencode would be a good method for urlparse. But this
will cease to exist with the addressing of 3108.

The patch is not applying cleanly.

BTW, urlparse has been renamed to urllib.parse, but the old docs are still
there (urlparse.rst).

Correction: the patch does apply cleanly to 2.6, without breaking tests.
It just needs to be ported to 3.0 (new urllib package).

• Updated patches for Python 2.6 and Python 3.0
• Moved the tests.
• Updated docs.

Somebody please review this so that it can checked in.

Hi Senthil, some details:

• You should not withdraw the parse_qsl from cgi.rst (btw, why didn't
  you extracted also the parse_qs one?), but put a Deprecation message,
  saying that the user should use it from the urlparse module.

• In cgi.py, in the added message "parse query string functions called
  from urlparse", you should say that this is for backward compatibility
  reasons.

• You defined an "unquote" function in urlparse.py. Isn't this function
  the same that already exists in urllib? Why can't you just use that one?

Thank you!!

Hi Facundo,
This issue/comments somehow escaped from my noticed, initially. I have
addressed your comments in the new set of patches.

1. Previous patch Docs had issues. Updated the Docs patch.
2. Included message in cgi.py about parse_qs, parse_qsl being present
   for backward compatiblity.
3. The reason, py26 version of patch has quote function from urllib is
   to avoid circular reference. urllib import urlparse for urljoin method.
   So only way for us use quote is to have that portion of code in the
   patch as well.

Please have a look the patches.
As this request has been present from a long time ( 2002-08-26 !), is it
possible to include this change in b3?

Thanks,
Senthil

This is ok, maybe with some small changes in the docs.

I asked in python-dev if this should go now or wait until 2.7/3.1

It seems like parse_multipart and parse_header are very strongly related
to parse_qs. (eg. if you want to process HTTP requests you'll want to
call parse_qs for x-www-form-urlencoded and parse_multipart for
multipart/form-data).

Should these be moved too? (They aren't part of the url syntax though,
so it doesn't make sense for them to be in urlparse).

Senthil, please update the patchs, adding a DeprecationWarning in 3.0 and
a PendingDeprecationWarning in 2.6.

Thanks!

Facundo, I have updated the patch against the trunk. Added the
PendingDeprecationWarning for py26 and DeprecationWarning for py3k.
All tests pass ok. Please verify and plan to apply this patch before rc1.

Commited in r66196 and r66199, this went into 2.6/3.0 rc1!!

Thank you all for the effort!