Deprecate the Parameter attribute pickle_default_value
Closes https://github.com/holoviz/param/issues/1007
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 87.94%. Comparing base (e6d7ae6) to head (84da955).
:warning: Report is 1 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #1019 +/- ##
=======================================
Coverage 87.93% 87.94%
=======================================
Files 9 9
Lines 4875 4877 +2
=======================================
+ Hits 4287 4289 +2
Misses 588 588
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
Draft for now as I'd like:
- https://github.com/holoviz/param/pull/1016 to be merged
- potentially the docstrings MR from @MarcSkovMadsen to be merged to (I'd like to update the docstring of
Parameterto mark pickle_default_value as deprecated
I think the problem that pickle_default_value was meant to address would still apply in 2025, in that pickling a value that is dependent on a particular run on a particular system can cause problems when unpickling, but if it's not been supported for some time, may as well worry about this issue next time it comes up in actual practice.
Yes, I agree that it sounds like it might be useful. But in practice, it seems like it was never implemented in Param, and no one reported setting pickle_default_value=False has no effect. So I agree that we can worry about it when this comes up again. In fact, deprecating it might lead someone to come here and ask for that feature to be implemented.
In the meantime, I'd like to push adding a metadata slot to Parameters (https://github.com/holoviz/param/issues/898). I think that would allow users to implement their own special Parameter handling without having to create their own Parameter class (I've had the need a few times to label Parameters differently in a class and abused precedence).
Unrelated test failures.