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
When upgrading pythonize from version 0.21.0 to version 0.23.0 in tantivy-py's quickwit-oss/tantivy-py#401, we switched from extract to extract_bound (per PyO3/pyo3#3916).
Now, we are hitting an issue where I64 values are becoming U64 after depythonize.
I came up with a solution in jamesbraza/tantivy-py#1 that involves re-casting U64 back to I64 if it fits, but this is pretty hacky.
Is there some way to preserve integer types across serialization/deserialization?
I64 values remaining I64
U64 values remaining U64
I am wondering if there is some way pythonize can accommodate this, maybe by adding an opt-in flag somewhere?
Also, I am not 100% sure if this is a pythonize vs pyo3 issue, but it seems to be a deserialization issue, so I opened this here.
The text was updated successfully, but these errors were encountered:
When upgrading
pythonize
from version0.21.0
to version0.23.0
intantivy-py
's quickwit-oss/tantivy-py#401, we switched fromextract
toextract_bound
(per PyO3/pyo3#3916).Now, we are hitting an issue where
I64
values are becomingU64
afterdepythonize
.I came up with a solution in jamesbraza/tantivy-py#1 that involves re-casting U64 back to I64 if it fits, but this is pretty hacky.
Is there some way to preserve integer types across serialization/deserialization?
I64
values remainingI64
U64
values remainingU64
I am wondering if there is some way
pythonize
can accommodate this, maybe by adding an opt-in flag somewhere?Also, I am not 100% sure if this is a
pythonize
vspyo3
issue, but it seems to be a deserialization issue, so I opened this here.The text was updated successfully, but these errors were encountered: