You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
decode's strict=False does not cast floats to ints #613
Currently, yeah. I could see adding support for coercing floats without a decimal component to integers though if needed (so 3.0 would be valid, but 3.5 would error). Can you say more about your use case here?
I'm ingesting in a format that deserializes all numerical values to floats, while the original type was an int. Since the original data were ints the floats end up being: 1.0, 6.0, etc.
At a high level, the data serialization is:
Original data in Python that contain ints
Serialize Python data into protobuf (the ints are preserved in this format)
Deserialize custom format into a json (where the ints gets converted into floats)
msgspec to convert json back into a Python type
I sense there is a bug in 3, so I likely do not require msgspec casting floats into ints.
I've added support for this in #619. Even though you said this likely wasn't necessary, it felt like something we could/should support (and supporting it was easy to do). Thanks for raising the issue!
Activity
jcrist commentedon Dec 13, 2023
Currently, yeah. I could see adding support for coercing floats without a decimal component to integers though if needed (so 3.0 would be valid, but 3.5 would error). Can you say more about your use case here?
thomasjpfan commentedon Dec 13, 2023
I'm ingesting in a format that deserializes all numerical values to floats, while the original type was an int. Since the original data were ints the floats end up being:
1.0, 6.0, etc.At a high level, the data serialization is:
msgspecto convert json back into a Python typeI sense there is a bug in 3, so I likely do not require
msgspeccasting floats into ints.jcrist commentedon Dec 20, 2023
I've added support for this in #619. Even though you said this likely wasn't necessary, it felt like something we could/should support (and supporting it was easy to do). Thanks for raising the issue!