[Chicago] Python 3.0 urllib.parse.urlencode()

David Beazley d-beazley at sbcglobal.net
Fri Feb 27 12:28:32 CET 2009

> Does this seem like something that has been overlooked, and should be
> the default behavior?  Python 3.0 has introduced some changes in the
> APIs here, and this appears to affect functionality that is unique  
> to 3.0.
> Additionally, it would seem to me that urlencode() itself should  
> take an
> "encoding" parameter, and possibly other parameters, that would be
> passed on to quote_plus().  However, that could be worked around as  
> long
> as urlencode() could use "bytes", as above.  (Actually, the above  
> ought
> to be extended to "k", as well as the "doseq" side of the if.)

I don't know if this is something that's been overlooked or not.   
However, I recently did a fairly thorough pass through the Python 3.0  
libraries when updating my book and found *numerous* problems/bugs  
related to inconsistent treatment of strings/bytes--especially with  
regard to encodings of binary data into text formats (Base 64, quopri,  
hex, etc.).  Just as an example:

 >>> base64.b64encode(b'hello')

Discussion: The purpose of base64 is to encode data into text.  So,  
should that result be a byte string or a text string?

It wouldn't surprise me if there are inconsistencies in other places  
(like urlencode).  You might check the Python bug tracker and submit a  
report to see what happens (the developers will let you know if they  
think it's expected behavior or not).


More information about the Chicago mailing list