-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support user-defined mapping for Inf and NaN via keyword arg #294
base: main
Are you sure you want to change the base?
Changes from 7 commits
d68937d
7d887c6
1ce1b28
f656813
62f8efb
0dc0277
4fc6b43
7f08318
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -46,6 +46,11 @@ end | |
@test JSON3.read("Inf"; allow_inf=true) === Inf | ||
@test JSON3.read("Infinity"; allow_inf=true) === Inf | ||
@test JSON3.read("-Infinity"; allow_inf=true) === -Inf | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Noting that it is not possible to support reading with a custom mapping defined with a function that maps However, it is possible to support reading and writing with a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I agree that not being able to read the JSON back in when a custom mapping is used is a bummer, but also it's something that is/will be better solved in JSONBase.jl, where it's easier to override reading things. Actually, we do have the RawJson construct if you really needed to parse something back in; it's a bit of a heavy-handed escape hatch here, but technically would work. |
||
|
||
quoted_inf_mapping(x) = x == Inf ? "\"Infinity\"" : x == -Inf ? "\"-Infinity\"" : "\"NaN\"" | ||
@test JSON3.write(NaN, inf_mapping = quoted_inf_mapping) == "\"NaN\"" | ||
@test JSON3.write(Inf, inf_mapping = quoted_inf_mapping) == "\"Infinity\"" | ||
@test JSON3.write(-Inf, inf_mapping = quoted_inf_mapping) == "\"-Infinity\"" | ||
end | ||
|
||
@testset "Char" begin | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This usage makes me think that
inf_mapping
should be a Tuple or NamedTuple rather than a function.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought so, too. But the function version was much faster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried arrays, tuples and functions, at least concerning writing. I didn't check read performance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also checked the RawType approach but I couldn't find out how to change the type to Float. The current approach looks more natural to me and has less code.
It is somewhat of a restriction that I only support the case of string mappings, but I think it is very untypical that people want to cover other values than Infinity and NaN if they have a process that allows to send non-standard JSON.
EDIT: it's easy to include the quotes just by expanding the view and leaving out the
[2:end-1]
so my previous comment is no longer valid.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difference between function and tuple that is giving you that performance difference is methods are specialized on a function but not on a tuple's value. You could get similar performance with a tuple by lifting it to the type domain with
Val
. I do see the advantage in terms of runtime performance of having the serialization format of inf and nan be passed into write/read at the type level