Closed macisamuele closed 4 years ago
@sjaensch for a couple of weeks I'll be far from a keyboard in order to make progress on this.
Definitely the point that you're raising is correct and that's the reason why I won't push more on introducing a similar feature until we don't have a clear idea on how to handle it.
I'll let you know when I get enough time to break the implementation and try to identify more weak points.
Looks good to me, but I see mypy and a test failure in the travis build. Could you take a look?
I was able to reproduce, locally, the test failure on Python 3.7, I'm going to update the test to fix the failure.
~The mypy failure is surprising to me as locally all looks good.~ ~I'll try to re-create a venv (with exactly the same dependencies) to try to reproduce the issue,~ The mypy failure is caused by the fact that the branch is not based on the latest master. Merging master into the branch makes the mypy reporting reproducible and so addressable.
This has been included in bravado-core 5.17.0.
The goal of this PR is to fix #370
In order to make
bravado_core.spec.Spec
pickable I had to define__getstate__
and__setstate__
methods intoSpec
andResource
class.The reason of this is that pickling an object usually gets all the object attributes and tries to pickle them:
Resource
does define__dir__
method which confuses the pickling processSpec
needs to deal with the fact that runtime created types (models) are not picklable. In order to make them pickable I'm pickling a representation of the arguments needed to rebuild the type. Unfortunately this approach has the defect that restoring (unpickling) the object might depend on the version of bravdo_core in use (more importantly on the signature ofcreate_model_type
. I think that this is eventually acceptable considering that the signature did not changed over time and that in case that would happen we could still ensure thatbavado_core.__version__
is encoded into the picklable object.