>
> But it does become worse if you have lots of classes you want to
> serialize. You need to write a default function somewhere that knows about
> all of your classes:
>
Somehow I didn't think of this until now, but when I've needed to use JSON
to serialize a non-trivial hierachy of types, I' es
On Sat, 17 Aug 2019 at 08:28, Andrew Barnert via Python-ideas
wrote:
> def jsonize_my_tree(obj):
> if isinstance(obj, MyTreeNode):
> return [obj.data(), *map(jsonize_my_tree, obj.children())]
> raise TypeError()
>
> myjson = json.dumps(my_thing_that_might_includ
Ah, that makes sense, thank you for the detailed example and explanation. I
had only read through the start of the previous topic, as it started to
become a bit difficult to follow (largely due to the author being
non-specific with what precisely they were looking for and the discussion
forking off
On Aug 16, 2019, at 20:35, Kyle Stanley wrote:
>
> Speaking of examples, I think it would be helpful to provide a brief example
> of ``object.__json__()`` being used for some added clarity. Would it be a
> direct alias of ``json.dumps()`` with the same exact parameters and usage, or
> would th
> True for yourself, I assume. But json.dumps is *not* why *the rest of
> us* do that. We do it because we've *always* done it. The Python
> objects we are serializing themselves lack units, precision, and pet's
> name! Until our Python programs become unit- and precision- aware,
> support for
On Thursday, August 15, 2019, Andrew Barnert wrote:
> On Aug 15, 2019, at 10:23, Christopher Barker wrote:
> >
> > This is all making me think it's time for a broader discussion / PEP:
> >
> > The future of the JSON module.
>
> I think this is overreacting. There’s really only two issues here, a
On Aug 15, 2019, at 10:23, Christopher Barker wrote:
>
> This is all making me think it's time for a broader discussion / PEP:
>
> The future of the JSON module.
I think this is overreacting. There’s really only two issues here, and neither
one is that major.
But nobody has shown any need for
This is all making me think it's time for a broader discussion / PEP:
The future of the JSON module.
*maybe* the way forward is to try to make a new "category killer" JSON lib
(or at least a platform for standard protocols). But it also may make sense
to start within Python itself -- at least for
On Thursday, August 15, 2019, Andrew Barnert wrote:
> On Aug 14, 2019, at 20:35, Wes Turner wrote:
>
> > A few questions then are:
> >
> > Should __json__() be versioned?
>
> Why? While there are sort of multiple versions of JSON (pre-spec, ECMA404,
> and the successive RFCs), even when you know
On Aug 14, 2019, at 20:35, Wes Turner wrote:
> A few questions then are:
>
> Should __json__() be versioned?
Why? While there are sort of multiple versions of JSON (pre-spec, ECMA404, and
the successive RFCs), even when you know which one you’re dealing with, there’s
not really anything you’d
Setting aside the arguments for just having reusable linked data JSON-LD in
the first place (which is also JSON that a non JSON-LD app can pretty
easily consume),
A few questions then are:
Should __json__() be versioned?
Should __json__() return JSON5 (with IEEE 754 ±Infinity and NaN)?
What prev
On Aug 14, 2019, at 19:48, Wes Turner wrote:
>
> Native serialization and deserialization support for either or both JSON5,
> JSON lines, and JSON-LD would be great to have.
PyPI has packages for all of these things (plus the two not-quite-identical
variations on JSONlines, and probably other
On Wednesday, August 14, 2019, Wes Turner wrote:
> There's JSON5; which supports comments, trailing commas, IEEE 754
> ±Infinity and NaN, [...]
> https://json5.org/
>
> There's also JSON-LD, which supports xsd:datetime, everything that can be
> expressed as RDF, @context vocabulary, compact and e
There's JSON5; which supports comments, trailing commas, IEEE 754 ±Infinity
and NaN, [...]
https://json5.org/
There's also JSON-LD, which supports xsd:datetime, everything that can be
expressed as RDF, @context vocabulary, compact and expanded
representations, @id, and lots of other cool features
On Aug 14, 2019, at 11:38, Chris Angelico wrote:
>
> Side point: Does anyone else think it was an egotistical idea to
> create JSON as a non-versioned specification? "I can't possibly get
> this wrong". And now look what's happened.
Well, it was supposed to be an antidote to complicated specific
On Thu, Aug 15, 2019 at 2:23 AM Random832 wrote:
>
> On Sun, Aug 11, 2019, at 20:42, Chris Angelico wrote:
> > class float:
> > def __json__(self):
> > if math.isfinite(self): return str(self)
> > return "null"
>
> Er, to be clear, the current JSON decoder returns 'Infinity', '
On Aug 14, 2019, at 09:22, Random832 wrote:
>
>> On Sun, Aug 11, 2019, at 20:42, Chris Angelico wrote:
>> class float:
>>def __json__(self):
>>if math.isfinite(self): return str(self)
>>return "null"
>
> Er, to be clear, the current JSON decoder returns 'Infinity', '-Infinity
On Sun, Aug 11, 2019, at 20:42, Chris Angelico wrote:
> class float:
> def __json__(self):
> if math.isfinite(self): return str(self)
> return "null"
Er, to be clear, the current JSON decoder returns 'Infinity', '-Infinity', or
'NaN', which are invalid JSON, not null. This beh
18 matches
Mail list logo
