feat: expose a visitor to deserialize a pyobject#65
feat: expose a visitor to deserialize a pyobject#65Stargateur wants to merge 1 commit intodavidhewitt:mainfrom
Conversation
davidhewitt
left a comment
davidhewitt
left a comment
There was a problem hiding this comment.
Sorry for the long delayed reply here. So I'm trying to understand the serialize / deserialize implementations. It looks like the idea (by virtue of using serde_transcode) is that this will allow serialization of a PyObject by first pulling it through depythonize and then pushing that through some other serializer (to e.g. produce a JSON string). Similar for the reverse, to go straight from a JSON string to a PyObject without first needing to go through some intermediate in-memory form.
Is that how you would describe it?
| where | ||
| D: serde::Deserializer<'de>, | ||
| { | ||
| Python::with_gil(|py| deserializer.deserialize_any(crate::PyObjectVisitor::new(py))) |
There was a problem hiding this comment.
Should this also use serde_transcode? I think in that way the PyObjectVisitor might not be needed, and instead we use Pythonizer here in the same way we use Depythonizer above?
2 participants
Working with pyo3 I end up needed this, user can implement it themself but I though it would be nice to have it in pythonize. Tell me what you think.
If the feature is not desired to avoid a dependency serde-transcode I think only expose the visitor is already good enough.