in Lib/Cookie.py, BaseCookie load() method performs the following comparison on line 624:

str(rawdata) == str("")

This breaks when a unicode string is passed in for rawdata. I've included a patch that fixes this issue by using isinstance(rawdata, basestring) comparison instead. Additionally the patch encodes rawdata in ascii before sending it to __ParseString() since that method does not support unicode.

Thanks for the report and patch.  This is not as easy as it sounds: The doc ambiguously uses “string”; the code clearly wants only byte strings (str); in the 3.x version, only character strings (unicode) are accepted; “raw” would suggest to me than only bytes make sense.

I would tend to edit the documentation but no the behavior, given that 2.7 is stable and this behavior has been present and documented for a long time.  Senthil, what’s your opinion?

The code was changed to do this in r83361 #3788.

> in the 3.x version, only character strings (unicode) are accepted
> The code was changed to do this in r83361 #3788.

That seems like a bug to me. It looks like the intention was to avoid the `type("")` check for stylistic reasons, so `isinstance(rawdata, str)` is an understandable translation under 3.1 (which #3788 targets), but I suspect that `type("")` should never have survived the transition to Python 3 in the first place. The 2.7 branch still has `type("")` (not `str("")` as originally reported):

https://hg.python.org/cpython/file/2.7/Lib/Cookie.py#l639


> “raw” would suggest to me than only bytes make sense.

Agreed. Cookie names and values are constrained to a subset of ASCII:

https://tools.ietf.org/html/rfc6265#section-4.1.1

I suggest cookies be thought of as a binary data store, with programmers responsible to encode/decode their data at the boundary with the cookies library.


> I would tend to edit the documentation but no[t] the behavior, given that 2.7 is stable and this behavior has been present and documented for a long time.

Leaving 2.7 as-is makes sense, but now I think it looks like we have a regression in 3, which should be fixed.

----

P.S. I arrived here from https://github.com/gratipay/aspen.py/pull/524.

Here's a patch with a couple failings tests for the type regression in 3.x.

Here's a patch that fixes the two new failing tests. Now a bunch of other tests are busted. :-)

Here's a start on converting to bytes everywhere for cookies. I'm not sure I fully understand the library's original worldview on type conversion. There's a value_{decode,encode} facility, and in the test suite attribute values in particular are often not even strings of any kind.

If strings and values are constrained to be ascii, there is no obvious reason to use bytes.  I don't see a bug here in python3.

Sorry, but changing to bytes after ten years of using str in this module in Python 3 is not going to happen. Let’s just document the state of Python 2 (see Éric: https://bugs.python.org/issue11315#msg129448).

Python 2.7 is no longer supported.