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 Wed, Aug 14, 2019 at 01:19:05PM -, Marat Sharafutdinov wrote:
> While using any library there is a need to handle exceptions it
> raises.
Is that true? For most exceptions, an exceptions means there is a bug in
your code. The exception is a sign that you are doing something wrong,
and h
On 14/08/2019 14:19:05, Marat Sharafutdinov wrote:
While using any library there is a need to handle exceptions it raises. In
ideal conditions author of library defines base exception and builds hierarchy
of exceptions based on it. Moreover, all exceptions a library raises (including
those t
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 Wed, Aug 14, 2019 at 11:34 PM Marat Sharafutdinov wrote:
>
> The essence of my idea is simple and does not affects compatibility with
> existing code: to automatically define a magic attribute of module under the
> working name "__exception__" while importing any module. It can be used in
>
On Aug 14, 2019, at 09:57, Christopher Barker wrote:
>
> The other issue on the table is whether it's a goal of the json module to
> make it hard to create invalid JSON -- I think that would be nice, but others
> don't seem to think so.
>
> A NOTE on that:
>
> Maybe it would be good to have a
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
Just trying to get a bit of clarification here.
We really do need to be clear on teh goals in order to choose the best
implementation.
> well, no -- we did not agree to that.
>
> Then I misread your statement:
>
> "I can't think of, and I don't think anyone else has come up with, any
> examples o
On Aug 14, 2019, at 06:19, Marat Sharafutdinov wrote:
>
>
> The essence of my idea is simple and does not affects compatibility with
> existing code: to automatically define a magic attribute of module under the
> working name "__exception__" while importing any module. It can be used in
> us
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
Sorry, the code was lost. I bring it again:
try:
any_module.anything
except any_module.__ exception__:
...
try:
any_function()
except any_function.__ exception__:
...
try:
AnyClass.anything
except AnyClass.__ exception__:
...
__
While using any library there is a need to handle exceptions it raises. In
ideal conditions author of library defines base exception and builds hierarchy
of exceptions based on it. Moreover, all exceptions a library raises (including
those that do not inherit its base exception) are documented a
16 matches
Mail list logo
