Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: -ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23123
___
___
Python-bugs-list
Mark Dickinson added the comment:
See also #16535.
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23123
___
___
Antoine Pitrou added the comment:
To cope with this potential problem, compliant parsers must preserve the
original textual representation of properties internally in order to support
JCS normalization requirements
That sounds ridiculous. Did someone try to reason the IETF guys? :)
Anders Rundgren added the comment:
Antoine Pitrou added the comment:
To cope with this potential problem, compliant parsers must preserve the
original textual representation of properties internally in order to support
JCS normalization requirements
That sounds ridiculous. Did someone
Antoine Pitrou added the comment:
I won't claim to know/understand the specifics, but message payload in base64
actually sounds reasonable to me, if far from optimal (both from readibility
and space overhead POV) :-).
--
___
Python tracker
Anders Rundgren added the comment:
Antoine Pitrou added the comment:
I won't claim to know/understand the specifics, but message payload in
base64 actually sounds reasonable to me, if far from optimal (both from
readibility and space overhead POV) :-).
It is indeed a working solution.
Raymond Hettinger added the comment:
Given that json is multi-language format ... I don't know
that we can expect much more from it.
JSON specifies a textual number format but doesn't dictate whether that format
represents a fixed precision binary float point number or a decimal floating
Anders Rundgren added the comment:
I guess my particular requirement/wish is unusual (keeping the original textual
representation of a floating point number intact) while using Decimal should be
fairly universal.
If these things could be combined in a Decimal support option I would (of
Bob Ippolito added the comment:
I don't think it's reasonable to expect Decimal to always output precisely the
same string it was given. It's a waste of complexity and space and the only
time you would want this behavior is when you really should've left it
accessible as a string in the first
Anders Rundgren added the comment:
Bob,
Your'e right, I have put up a requirement for JSON serializing that may be
over the top. OTOH, there are (AFAICT...) only two possible solutions:
1. Outlaw floating point data from the plot
2. Insist that serializers conform to the spec
As a pragmatic I
Anders Rundgren added the comment:
Well, I could have insisted on canonicalization of floating-point data but
that's so awkward that outlawing such data is a cleaner approach. Since the
target for JCS is security- and payment-protocols, I don't think the absence of
floating-point support
Anders Rundgren added the comment:
Using simplejson I got it to work!!!
I just wonder what you think of the solution:
import collections
import simplejson as json
from decimal import Decimal
class EnhancedDecimal(Decimal):
def __str__ (self):
return self.saved_string
def
Bob Ippolito added the comment:
Yeah, that's the hack I was suggesting.
I suppose I don't see the point of having a protocol that normalizes *almost*
everything. Normalization should be all or nothing. Other options would be to
define the signature at the encoded byte level with no
Anders Rundgren added the comment:
Bob,
I'm not sure I understand why you say that JCS requires *almost* full
normalization. Using browsers you can generate fully compliant JCS objects
using like 20 lines of javascript/webcrypto (here excluding base64 support).
No normalization step is
Anders Rundgren added the comment:
The current JCS validator is only 150 lines and does both RSA and EC signatures:
https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json/JCSValidator.py
My Java-version is much more advanced but this is quite useful anyway
Ethan Furman added the comment:
Raymond Hettinger added the comment:
---
This bug report isn't a JSON spec issue; rather, it is about how the JSON
module API can
support (or inhibit) valid use cases.
AFAICT, the patch to make the API better support enums
Anders Rundgren added the comment:
Ethan Furman added the comment:
I am not a regular json user, but my impression is the format is
pretty basic, and we would be overloading it to try and keep numbers
with three decimal places as Decimal, and anything else as float.
Isn't json's main
Raymond Hettinger added the comment:
It is unfortunate that there doesn't seem to be a way to round-trip Decimals.
That would seem to be a fundamental capability that we should expect to support.
I have a vague recollection that you used to be able to trick the encoder by
returning a
Ethan Furman added the comment:
Enums (and other numeric subclasses), do not round-trip back to themselves. An
IntEnum with the value of 4 is written as 4 and converted back from json as the
integer 4 (not Settings.TabSpaces, or whatever).
Given that json is multi-language format (or a
Bob Ippolito added the comment:
simplejson has had a use_decimal flag for output since 2.1.0 and has been
enabled by default since 2.2.0. simplejson 3.2.0 introduced a for_json argument
that checks objects for a method of that name for serialization.
Anders Rundgren added the comment:
I was actually hoping to implement the final part of this:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html#Normalization_and_Signature_Validation
It seems that the current Decimal implementation wouldn't save me anyway since
it modifies
Bob Ippolito added the comment:
I'm sure there's some hack that would allow you to preserve the input. I would
try using parse_float and have it return some object that preserves the string
and will be output in precisely the same way. It may need to be a Decimal
subclass. I'm traveling for
Anders Rundgren added the comment:
It would be great if I could use a sub-classed Decimal during parsing but since
it doesn't appear to be a way to serialize the result using the json package
I'm probably stuck with the current 99% solution.
I have solved this in Java and JavaScript by
Bob Ippolito added the comment:
Subclass Decimal and implement __str__ to return your own representation. Use
parse_float to use your Decimal subclass. Should work with simplejson, a
similar hack may be possible with the json module.
--
___
Python
New submission from Anders Rundgren:
jsonString = '{t:6,h:4.50, g:text,j:1.40e450}'
jsonObject = json.loads(jsonString,
object_pairs_hook=collections.OrderedDict,parse_float=Decimal)
for item in jsonObject:
print jsonObject[item]
6
4.50
text
1.40E+450
Works as expected.
However, there seems
25 matches
Mail list logo
