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
Today, nearly all framework *Predictor classes (with the exception of TensorFlowPredictor - yay for TF!) forcibly set the serializer and deserializer.
While implementing an appropriate default behaviour for each framework is great, it would be much nicer if classes like PyTorchPredictor implemented the same de/serializer constructor options as the base Predictor - and just defaulted these values when not provided.
...which may seem minor, but is important because the main API documentation only covers methods, not properties: So it's not actually obvious to new users that modifying the value of predictor.serializer is supported.
It would also provide an opportunity to explicitly note what the default de/serialization is in each framework's docs - which would bring useful clarity!
Describe alternatives you've considered
N/A
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered:
Describe the feature you'd like
Today, nearly all framework
*Predictor
classes (with the exception of TensorFlowPredictor - yay for TF!) forcibly set theserializer
anddeserializer
.While implementing an appropriate default behaviour for each framework is great, it would be much nicer if classes like PyTorchPredictor implemented the same de/serializer constructor options as the base Predictor - and just defaulted these values when not provided.
How would this feature be used? Please describe.
Instead of the currently required:
User would be able across all frameworks (like they currently can for TensorFlow) to:
...which may seem minor, but is important because the main API documentation only covers methods, not properties: So it's not actually obvious to new users that modifying the value of
predictor.serializer
is supported.It would also provide an opportunity to explicitly note what the default de/serialization is in each framework's docs - which would bring useful clarity!
Describe alternatives you've considered
N/A
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: