Anders Rundgren <anders.rundgren@gmail.com> added the comment:
Thanx for the superquick response!
I really appreciate it.
I'm obviously a Python n00b
Anders
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Anders Rundgren <anders.rundgren@gmail.com>:
Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6 2015, 01:54:25) [MSC v.1900 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
Anders Rundgren added the comment:
In ES6/V8-compatible implementations which include "node.js", Chrome, Firefox,
Safari and (of course) my Java reference implementation you can take a
cryptographic hash of a JSON object with a predictable result.
That is, this request is in no w
Anders Rundgren added the comment:
An easier fix than mucking around in the pretty complex number serializer code
would be adding an "ES6Format" option to the "json.dump*" methods which could
use the supplied conversion code as is.
For JSON parsing in an ES6-compatible way
Anders Rundgren added the comment:
As I said, the problem is close to fixed in 3.5.
You should not consider the JCS specification as the [sole] target but the
ability to creating a normalized JSON object which has many uses including
calculating a hash of such objects
New submission from Anders Rundgren:
According to the documentation repr() and str() are different when it comes to
number formatting. A test with a 100 million random and selected IEEE 64-bit
values returned no differences
--
components: Interpreter Core
messages: 259244
nosy
Anders Rundgren added the comment:
Apparently the docs have changed since 2.7:
https://docs.python.org/3.5/tutorial/floatingpoint.html
However, the documentation still "sort of" mentions repr() as the most accurate
form which isn't entirely correct since it nowadays is identi
New submission from Anders Rundgren:
ECMA has in their latest release defined that JSON elements must be ordered
during serialization. This is easy to accomplish using Python's OrderedDict.
What is less trivial is that numbers have to be formatted in a certain way as
well. I have tested
New submission from Anders Rundgren:
pip install Crypto
Terminates correctly and the package is there as well.
Unfortunately the directory is named "crypto" rather than "Crypto" so when I
perform
>>>import Crypto
the interpreter fails.
>>>import cryp
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
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
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
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 __new__
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
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
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
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
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
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
21 matches
Mail list logo
