Repository navigation
[ENH]: Add mechanism for feature flags #30519
Description
Problem
Introducing fundamental behavioral changes like registering standalone figures #29855, GUI-native drawing elements #30516, or the data prototype may cause unforeseen side effects.
Proposed solution
It may be worthwhile to make them toggleable through flags. This would allow to
- ship experimental features and allow early adopters to try them out by opt-in
- if the flag is active by default, users have the chance to opt out if the feature breaks their work
Activity
anntzer commented on Sep 5, 2025
That's just rcParams entries? Or do you envision something else?
timhoffm commented on Sep 5, 2025
Maybe, maybe not.
Semantically, they are different from regular config parameters. I expect that they come, stay for some time and then are removed again. It may also be quite common that we switch from opt-in to opt-out. I have to think whether the rcParams tooling is suitable for that, e.g. rcParams raise if the the parameter does not exist - would we maybe just warn on feature flags? Also to make sure they are not mixed up with regular parameters, I'd at least use a dedicated namespace like rcParams["flags.scroll_to_zoom"].
Another aspects could be that some changes may be needed to be decided upon prior to loading the rcParams.
anntzer commented on Sep 5, 2025
Sure, a dedicated namespace (possibly with slightly tweaked semantics e.g. wrt missing flags or deprecation rules) looks fine.
jklymak commented on Sep 5, 2025
It seems to me we have things that belong in rcparams like the behaviour of the scroll wheel that can be handled by simply changing the default
I'm not clear on how registering standalone figures into pyplot is anything that requires a toggle because the user needs to do something?
A big infrastructure change like the data prototypes or mpl-gui seem like they should be alternate submodules if we want to allow toggling them?
aman-coder03 commented on Feb 12, 2026
I have been reading through this discussion and I’m trying to better understand the intended scope.
Would the goal be a lightweight mechanism specifically for experimental features (with slightly different semantics from regular rcParams), or something more general that could be reused longer term?
If helpful, I would be interested in exploring a small prototype for how a flags.* namespace might integrate with the existing rcParams machinery.