Storing instances using jsonpickle

[Terry Reedy]

On 9/6/2014 12:32 PM, MRAB wrote:
> On 2014-09-06 01:20, Chris Angelico wrote:
>> On Sat, Sep 6, 2014 at 3:04 AM, MRAB <python at mrabarnett.plus.com>
>> wrote:
>>> JSON has 'true' and 'false'.
>>>
>>> Python has 'True' and 'False'.
>>>
>>> Therefore, if you want it to be able to drop it into Python's REPL,
>>> it won't be compatible with JSON anyway! (Well, not unless you
>>> define 'true' and 'false' first.)
>>
>> This is a new spec, so I guess the question is whether it's
>> primarily "JSON with some more features" or "subset of Python syntax
>> in the same way that JSON is a subset of JS". If it's the former,
>> then yes, it'd use "true" and "false", and you'd have to define them;
>> but if the latter, the spec would simply use "True" and "False". But
>> being able to guarantee that JSON decodes correctly with this parser
>> (ie make it a guaranteed superset of JSON) would be of value.
>>
> I've found that there's another issue with JSON: string escapes include
> \u, but not \U:
>
>  >>> json.dumps('\U0010FFFF')
> '"\\udbff\\udfff"'
>
> Yes, it uses surrogate escapes!

Because Javascript does.  It does roundtrip properly (3.4.1)
 >>> json.loads('"\\udbff\\udfff"')
'\U0010ffff'

> Also:
>
>  >>> json.dumps('\uDBFF\uDFFF')
> '"\\udbff\\udfff"'
>
> so it won't round-trip.
>
> On the other hand, you probably won't be using pairs of surrogate
> escapes in Python 3.3.

The surrogate codepoints are not unicode characters and as I remember 
from reading the standard, would not be allowed in a strict utf-32 
implementation.  3.3+ uses them, when requested, to represent 
undecodable bytes in a non-standard fashion.
and for other occasional practical reasons that most of us can ignore.

-- 
Terry Jan Reedy