On 11/25/21 23:00, Robert Kern wrote:
We could also provide a JSONEncoder/JSONDecoder pair, too, but as I
mention in one of the Github issues you link to, there are a number of
different expectations that people could have for what the JSON
representation of an array is. Some will want to use the JData
standard. Others might just want the arrays to be represented as lists
of lists of plain-old JSON numbers in order to talk with software in
other languages that have no particular standard for array data.
hi Robert
I agree with you that different users have different expectations, but
if you want, this can be accommodated by defining slightly different
(builtin) subclasses of JSONEncoder functions and tell users what to
expect when using those with cls=.... , or use one JSONEncoder and
different parameters.
other projects like pandas.DataFrame handle this via a format parameter
("orient") to the to_json() function
https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.to_json.html
from my limited experience, as long as the "TypeError" from json keeps
popping up, requests like this ( #12481, #16432, #18994,
pallets/flask#4012, openmm/openmm#3202, zarr-developers/zarr-python#354)
will unlikely to cease (and maintainers will have to keep on closing
with "wontfix") - after all, no matter how different the format
expectations a user may have, seeing some sort of default behavior is
still a lot more satisfying than seeing an error.
It seems to me that the jdata package is the right place for
implementing the JData standard. I'm happy for our documentation to
point to it in all the places that we talk about serialization of
arrays. If the json module did have some way for us to specify a
default representation for our objects, then that would be a different
matter. But for the present circumstances, I'm not seeing a
substantial benefit to moving this code inside of numpy. Outside of
numpy, you can evolve the JData standard at its own pace.
--
Robert Kern
I appreciate that you are willing to add this to the documentation, that
is totally fine - I will just leave the links/resources here in case
solving this issue becomes a priority in the future.
Qianqian
_______________________________________________
NumPy-Discussion mailing list --numpy-discussion@python.org
To unsubscribe send an email tonumpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address:fan...@gmail.com
_______________________________________________
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
