On Thu, 8 Aug 2019 at 22:31, Richard Musil wrote:
>
> I have not asked for means to serialize invalid JSON objects. Yes, with the
> "raw" output, you can create invalid JSON, but it does not mean you have to.
True. But my point was simply that the json module appears to be
designed in a way that
@Richard I suggest you open a new thread to discuss support for dumping
`Decimal` as a number in JSON.
I agree that allowing arbitrary strings to be inserted in the JSON is not a
good idea, but apart from the `Decimal` issue I can't think of any other case
that can't be solved via `JSONEncoder.
Please, let me explain once more what want.
I need a JSON codec (serializer-deserializer), which can preserve its input on
its output. After some thought it seems to be really concerning only the
floats. (The attempt to generalize this should be regarded as secondary - just
suggestion subject t
@Dominik, I believe your proposal (if I understand it correctly) will break it
for people, who are already serializing the decimal.Decimal into the string
(for lack of better support).
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscr
On the second though though, what you propose should work right, if:
1) json.dumps will be extended to accept `dump_float` keyword argument, which
would accept a custom class (for example decimal.Decimal, but could the same
one which was specified with `parse_float`).
2) Then the serializer whe
Richard Musil writes:
> After some thinking it seems that the float is only case where this
> "loss of a precision" happen.
I don't think so. What's happening here is not restricted to "loss of
precision".
This can happen for any type that has multiple JSON representations of
the same interna
On 08/08/2019 21:18, Richard Musil wrote:
2) Use JSON decoder to decode it (hopefully without losing anything in the process) and
then dump it into "normalized" form and compute the hash over this one. This
has the risk of conversion error, but if I could avoid that risk by using a custom type
JSON objects are specified by their textual representation (json.org). Choosing
some binary representation for them (so they can be processed efficinetly)
which does not preserve their value is the problem of the underlying binary
representation, not of the JSON format per se.
__
There is no "normalized" representation for JSON. If you look at the "standard"
it is pretty simple (json.org). The JSON object is defined solely by its
textual representation (string of characters).
The way how different parsers choose to represent it in the binary form, so
they can process it
On Fri, 9 Aug 2019 at 15:20, Richard Musil wrote:
>
> JSON objects are specified by their textual representation (json.org).
> Choosing some binary representation for them (so they can be processed
> efficinetly) which does not preserve their value is the problem of the
> underlying binary repr
The documentation is beautiful.
One of the features I was looking for when evaluating parsers was the
ability to run expression on the rules. For example if you matching
"\begin{\w*}"
and \w* turns out to be "enumeration", then later when you match
"\end{\w*}"
then you want to check that that \w
On Thu, 8 Aug 2019 at 18:53, Chris Angelico wrote:
> On Fri, Aug 9, 2019 at 6:31 AM Richard Musil wrote:
> >
> > Chris Angelico wrote:
> >
> > > 2) Should there be a protocol obj.__json__() to return a string
> > > representation of an object for direct insertion into a JSON file?
> >
> > > Howe
On 09/08/2019 16:05, Joao S. O. Bueno wrote:
I spent some minutes now trying to encode a Decimal as a JSON "Number" using
Python native encoder - it really is not possible. The level of
customization
for Python encoders just allows a method ("default") that have to return
a "known" object type -
So -
I think that is clear by now that in your case you really are not loosing
any precision with these numbers.
However, as noted, there is no way to customize Python JSON encoder
to encode an arbitrary decimal number in JSON, even though the standard does
allow it, and Python supports then via d
Alright hear me out here:
I've often found that it would be useful for the following type of
expression to be condensed to a one-liner:
def running_average(x_seq):
averages = []
avg = 0
for t, x in enumerate(x_seq):
avg = avg*t/(t+1) + x/(t+1)
averages.append(avg)
On Aug 9, 2019, at 07:25, Richard Musil wrote:
>
> There is no "normalized" representation for JSON. If you look at the
> "standard" it is pretty simple (json.org). The JSON object is defined solely
> by its textual representation (string of characters).
json.org is not the standard; RFC 8259
On Thu, Aug 8, 2019 at 5:24 PM Sebastian Kreft wrote:
>
>
> On Thu, Aug 8, 2019 at 7:09 PM Andrew Barnert via Python-ideas <
> python-ideas@python.org> wrote:
>
>> On Aug 8, 2019, at 15:01, Ryan Fox wrote:
>>
>> I don't see why you would want to access arguments by their position.
>>
>>
>> Becau
On Aug 9, 2019, at 08:47, Peter O'Connor wrote:
>
> I've often found that it would be useful for the following type of expression
> to be condensed to a one-liner:
>
> def running_average(x_seq):
> averages = []
> avg = 0
> for t, x in enumerate(x_seq):
> avg = avg*t/(t+
On Thu, Aug 8, 2019 at 11:38 AM Ryan Fox wrote:
> Thanks for the comments.
>
> I'm not really sure what you mean with regards to backwards compatibility.
> Would it suffice to have ExceptionTemplate.__init__ accept *args and pass
> that into super().__init__? I see that BaseException does somethi
On Fri, Aug 9, 2019 at 9:03 AM Peter O'Connor
wrote:
> Alright hear me out here:
>
> I've often found that it would be useful for the following type of
> expression to be condensed to a one-liner:
>
> def running_average(x_seq):
> averages = []
> avg = 0
> for t, x in enumerate(x_seq)
Alright, when I made the reference to the json.org I made a mistake. Should
have made the reference to the RFC. You are right that the RFC makes it clear
that it is aware of possible interoperability problems and that some "common
ground" should be acceptable for the underlying representation.
Joao S. O. Bueno wrote:
> However, as noted, there is no way to customize Python JSON encoder
> to encode an arbitrary decimal number in JSON, even though the standard does
> allow it, and Python supports then via decimal.Decimal.
> Short of a long term solution, like a __json__ protocol, or at le
On Fri, Aug 9, 2019 at 12:55 PM Brett Cannon wrote:
>
>
> On Thu, Aug 8, 2019 at 5:24 PM Sebastian Kreft wrote:
>
>>
>>
>> On Thu, Aug 8, 2019 at 7:09 PM Andrew Barnert via Python-ideas <
>> python-ideas@python.org> wrote:
>>
>>> On Aug 8, 2019, at 15:01, Ryan Fox wrote:
>>>
>>> I don't see why
On 09/08/2019 18:10, Brett Cannon wrote:
On Fri, Aug 9, 2019 at 9:03 AM Peter O'Connor
wrote:
Alright hear me out here:
I've often found that it would be useful for the following type of
expression to be condensed to a one-liner:
def running_average(x_seq):
averages = []
avg = 0
On Fri, 9 Aug 2019 at 14:49, Richard Musil wrote:
> Joao S. O. Bueno wrote:
>
> > However, as noted, there is no way to customize Python JSON encoder
> > to encode an arbitrary decimal number in JSON, even though the standard
> does
> > allow it, and Python supports then via decimal.Decimal.
> >
> If you’re wondering why this works, it’s because Error and InputError
don’t override __new__. Which should make it obvious why a tutorial aimed
at novices doesn’t get into the details, but that’s why Python has
reference manuals instead of just a tutorial.
Between the links I've found, none of t
Joao S. O. Bueno wrote:
> yes, just that it should be called dump_as_float and take either a
> class
> or a tuple-of-classes
I saw kind of symmetry with the `parse_float` which only accepted one class for
having only one class on the output as well. Besides there are probably not
many (differen
On Aug 9, 2019, at 12:00, Ryan Fox wrote:
>
> > If you’re wondering why this works, it’s because Error and InputError don’t
> > override __new__. Which should make it obvious why a tutorial aimed at
> > novices doesn’t get into the details, but that’s why Python has reference
> > manuals inste
Stephen J. Turnbull wrote:
Richard Musil writes:
> After some thinking it seems that the float is only case where this
> "loss of a precision" happen.
This is true of Unicode normalized forms as well as floats.
But it's true in Python, where you have the option to not normalise
your deseria
Peter O'Connor wrote:
> Alright hear me out here:
> I've often found that it would be useful for the following type of
> expression to be condensed to a one-liner:
> def running_average(x_seq):
> averages = []
> avg = 0
> for t, x in enumerate(x_seq):
> avg = avg*t/(t+1) + x/(t
Richard Musil wrote:
Even the number
0.64417266845703130 (note the last 0) is different JSON object from
0.6441726684570313 (without the last 0).
And Python's Decimal type preserves that distinction:
>>> Decimal("0.64417266845703130")
Decimal('0.64417266845703130')
>>> Decimal("0.6441726684570
Paul Moore wrote:
So you're proposing a change to the Python
language stdlib implementation of that translation. Fine. But you have
yet to provide a justification for such a change,
I think it can be justified on the grounds that it allows all of the
information in the JSON text to be preserved
Joao S. O. Bueno wrote:
Short of a long term solution, like a __json__ protocol, or at least special
support in Python json module for objects of type "numbers.Number",
the only way to go, is, as you are asking, being able to insert "raw
strings into json".
No, that's not the only way. It wou
Rhodri James wrote:
I get what you want -- "this string of digits is the
representation I want to use, please don't put quotes around it" -- but
I can't help but feel that it will only encourage more unrealistic
expectations.
I think "consenting adults" applies here. Yes, you could use it to
On Aug 9, 2019, at 17:16, Greg Ewing wrote:
>
> I think it can be justified on the grounds that it allows all of the
> information in the JSON text to be preserved during both deserialisation
> and serialisation.
Except that it doesn’t allow that. Using Decimal doesn’t preserve the
difference b
On Fri, 9 Aug 2019 at 19:53, Richard Musil wrote:
> Joao S. O. Bueno wrote:
> > yes, just that it should be called dump_as_float and take either a
> > class
> > or a tuple-of-classes
>
> I saw kind of symmetry with the `parse_float` which only accepted one
> class for having only one class on th
On Aug 9, 2019, at 17:53, Greg Ewing wrote:
>
> If you really insist on being strict, it could require you to
> return a special wrapper type that takes a string of digits and
> checks that it conforms to the syntax of a JSON number.
>
> Come to think of it... you could use Decimal as that wrapp
On Aug 9, 2019, at 17:44, Greg Ewing wrote:
>
> Since Python's Decimal preserves all the information in the JSON
> representation of a float (including trailing zeroes!), anything
> else you might want can be achieved by pre/postprocessing the
> decoded data structure.
>
> It's just occurred to
Andrew Barnert wrote:
Except that it doesn’t allow that. Using Decimal doesn’t preserve the
difference between 1.E+3 and 1000.0, or between +12 and 12.
That's true. But it does preserve everything that's important for
interpreting it as a numerical value without losing any precision,
which
Andrew Barnert wrote:
No you can’t. Decimal accepts strings that aren’t valid as JSON numbers, like
`.3`,
That's not a problem as long as it doesn't serialise them that
way, which it wouldn't:
>>> str(Decimal('.3'))
'0.3'
> or `nan`,
The serialiser could raise an exception in that case.
BTW
40 matches
Mail list logo
