Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make QAMExecutionResult serializable #1719

Open
MarquessV opened this issue Dec 18, 2023 · 2 comments
Open

Make QAMExecutionResult serializable #1719

MarquessV opened this issue Dec 18, 2023 · 2 comments
Assignees
Labels
enhancement ✨ A request for a new feature.

Comments

@MarquessV
Copy link
Contributor

Due to using non-picklable members from qcs-sdk-python, QAMExecutionResult is not itself serializable. We should add a way to pickle it, either by supporting pickling upstream or implementing it for QAMExecutionResult specifically.

@MarquessV MarquessV added the enhancement ✨ A request for a new feature. label Dec 18, 2023
@MarquessV MarquessV self-assigned this Dec 18, 2023
@jselig-rigetti
Copy link
Contributor

This would also be useful for pyquil.api._qpu.QPUExecuteResponse so that programs can be submitted and retrieved in separate programs.

@petergthatsme
Copy link

Yes this would be great. Also, instead of the program data/results disappearing after it's been retrieved by the user (as happens now, from what i understand), it would be great, if it stays available for some (even short) time after, say a day or two. That would allow users to handle potential intermittent retrieval/network/whatever issues (e.g. users tries to retrieve job data, rigetti server sends it over and marks as retrieved, removing relevant data, then something happens along the way and users does not see it... they then can't try to retrieve again, as server thinks that's been done and potentially got rid of it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement ✨ A request for a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants