Add copy support to Scenario#3166
Conversation
|
Performance benchmarks:
|
|
With #3168 merged, I see even less reason for this. Because you can just subclass a scenario with default values and then create new instances from this with only the relevant parameters changed. So again, can you give me a clear practical example of why this would be needed. I disagree with the naming. A copy should return a copy, not contain support for also changing the content. In fact, I am considering making Scenario instances fully frozen. This removes the need for the internal model attribute and |
|
Thanks for the discussion. With the subclassing approach from #3168, I agree that there is no strong need for this anymore: when parameters are known ahead of time, subclassing provides a clean solution, and for fully dynamic cases the existing explicit construction patterns remain available, even if more verbose. Given that, I’m happy to close this PR and focus on follow-up contributions aligned with the new Scenario design. |
Scenario Copy Utility
Motivation
When running experiment sweeps, ablations, or parameter tuning, it is common to create multiple variants of a base scenario with small parameter changes.
Manually reconstructing scenarios is:
_scenario_idor other hidden attributes can cause subtle bugs.This utility introduces a simple, explicit API for cloning scenarios while preserving reproducibility guarantees.
Implementation
copy(**updates)method to theScenarioclass._scenario_idmodelreferenceExamples
Without Copy
It has three problems
With Copy
Additional Context
solves #3159.