[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')
b'aGVsbG8='
>>>
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).
Cheers,
Dave
More information about the Chicago
mailing list