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

Instance-level dispatch table #395

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ogrisel
Copy link
Contributor

@ogrisel ogrisel commented Sep 22, 2020

This change is necessary to make it natural to subclass CloudPickler with a per-instance, custom dispatch table.

joblib/loky#260

I also took the opportunity to make it such that dispatch_table are isolated by default: meaning that mutated one does not impact other instances.

I still need to document this change in a changelog entry.

ping @pierreglaser @tomMoral @jakirkham you might be interested in this.

@codecov
Copy link

codecov bot commented Sep 22, 2020

Codecov Report

Merging #395 into master will decrease coverage by 8.94%.
The diff coverage is 50.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #395      +/-   ##
==========================================
- Coverage   91.61%   82.67%   -8.95%     
==========================================
  Files           3        3              
  Lines         656      658       +2     
  Branches      135      135              
==========================================
- Hits          601      544      -57     
- Misses         34       90      +56     
- Partials       21       24       +3     
Impacted Files Coverage Δ
cloudpickle/cloudpickle_fast.py 79.35% <50.00%> (-17.40%) ⬇️
cloudpickle/compat.py 70.00% <0.00%> (-30.00%) ⬇️
cloudpickle/cloudpickle.py 86.09% <0.00%> (-0.60%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d3279a0...d6a0263. Read the comment docs.

Copy link
Member

@jakirkham jakirkham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Olivier! 😄 This seems like a nice improvement. Had a small question below

# and get the C implementation of Pickler take the
# re-assignment into account.
self.dispatch_table = ChainMap(
{}, # to register instance-level custom reducers
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have an internal variable to point to this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good suggestion. I still need to find the time to understand the cause of the PyPy segfault.

@ogrisel
Copy link
Contributor Author

ogrisel commented Sep 23, 2020

Actually before considering merging this change we might also want to do some benchmark. Maybe ChainMap is not that fast when doing many consecutive getitems with maybe misses on the first map which will be empty most of the time.

@ogrisel
Copy link
Contributor Author

ogrisel commented Sep 24, 2020

Note that we found a workaround for the problem we got in the subclass in loky: joblib/loky#272. Still this behavior is really unexpected so instance level isolation and lazy init of the dispatch_table might be more intuitive for other subclassing this Pickler.

@jakirkham
Copy link
Member

Yeah this change still seems reasonable to me FWIW 🙂

faucct pushed a commit to mrMakaronka/pyenv that referenced this pull request Apr 13, 2021
@faucct
Copy link

faucct commented Apr 13, 2021

Out project has just stumbled on this issue. What is left to do? Do you need any help completing this?

@jakirkham
Copy link
Member

Probably still the PyPy segfaulting issue noted here ( #395 (comment) )

@ogrisel
Copy link
Contributor Author

ogrisel commented Oct 13, 2023

@pierreglaser this PR requires to be updated (or reworked from scratch) now that we merged #517.

I plan to tag 3.0.0 today and publish to pypi.org and conda-forge on Monday, so I don't want to do that work for 3.0.0.

But if anybody is interesting in working on this, we could cut a quick 3.1.0 release in the coming weeks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants