Several times I have used six to port a module to Python 3 and I had to add my own code to handle these. So it would be useful to handle these in six so that everyone that uses six can use them and doesn't need to add their own code.
I've always been wary about mapping the whole urllib2/urlparse mess. Since so many things moved around cross-modules, it's hard to create a sensical naming scheme. Rather than adding several functions at a time like this patch, I would prefer to see a whole compatibility layer for the entire urllib renaming, perhaps by faking the urllib modules on Python 2. This way we could get a nice consistent interface.
One problem particular to this implementation is that it's not lazy.
OK, in fc8f512, I changed to more of a lazy implementation and made it work with all of the functions in Python 3's urllib.parse that also exist in Python 2 (notably omitting quote_from_bytes and unquote_to_bytes, because they don't exist in Python 2). What's bugging me a bit is that I had to create a new .py file for the urllib_parse stuff, but I suspect I could probably get it back to a single file.
In 8d699c7, I got rid of the extra file (six_urlparse.py) and got it back to being all in a single file (six.py).
I'm on the fence as to whether these functions should stay in six.moves.urllib_parse or if I should try to move them to six.moves.urllib.parse (dot instead of an underscore; a little more like the Python 3 structure so perhaps a tad nicer?). On the other hand, six already has a precedent for doing the underscore style as it has mapped Python 3's urllib.robotparser to six.moves.urllib_robotparser. So maybe it's fine as it is?
As I've started migrating my projects to unified code bases, I find I'm only recently using six now, but I've still been putting conditional imports for urllib modules I use. I'd very much like this to be a part of the package.