`default=True` on feature flags is order-sensitive

[jwodder]

The following code:

import click


@click.command()
@click.option("--red", "color", flag_value="red")
@click.option("--green", "color", flag_value="green", default=True)
@click.option("--blue", "color", flag_value="blue")
def main(color: str) -> None:
    print(repr(color))


if __name__ == "__main__":
    main()

when run with no arguments using click 8.2.1 outputs 'green', which is what I expect. If click 8.3.0 is used instead, then it outputs None — but if the --green option is moved above the --red option in the script, click 8.3.0 will output 'green'.

I believe that the script should output 'green' regardless of the declaration order of the options.

Environment:

• Python version: 3.13.7
• Click version: 8.2.1 and 8.3.0

[sirosen]

I've worked out a patch for this which seems to work, and which passes current tests, but I need to create new test cases to capture this behavior.

diff so far

diff --git a/src/click/core.py b/src/click/core.py
index ff2f74a..2f84b26 100644
--- a/src/click/core.py
+++ b/src/click/core.py
@@ -1216,6 +1216,12 @@ class Command:
         for param in iter_params_for_processing(param_order, self.get_params(ctx)):
             _, args = param.handle_parse_result(ctx, opts, args)
 
+        # after handling *all* parameters, do a pass over the params to rewrite
+        # `UNSET`
+        for name, value in ctx.params.items():
+            if value is UNSET:
+                ctx.params[name] = None
+
         if args and not ctx.allow_extra_args and not ctx.resilient_parsing:
             ctx.fail(
                 ngettext(
@@ -2528,17 +2534,20 @@ class Parameter:
             # We skip adding the value if it was previously set by another parameter
             # targeting the same variable name. This prevents parameters competing for
             # the same name to override each other.
-            and self.name not in ctx.params
+            and (
+                self.name not in ctx.params
+                or ctx.params[self.name] is UNSET
+            )
         ):
             # Click is logically enforcing that the name is None if the parameter is
             # not to be exposed. We still assert it here to please the type checker.
             assert self.name is not None, (
                 f"{self!r} parameter's name should not be None when exposing value."
             )
-            # Normalize UNSET values to None, as we're about to pass them to the
-            # command function and move them to the pure-Python realm of user-written
-            # code.
-            ctx.params[self.name] = value if value is not UNSET else None
+            # Do not normalize UNSET values to None at this point
+            # It needs to be done, but doing so too early impacts multiple parameters
+            # targeting the same variable name
+            ctx.params[self.name] = value

Basically, the issue is, at a coarse level, what you might guess: "something to do with UNSET vs None." Specifically, by converting UNSET to None too early during parsing, it becomes impossible to tell whether or not default=None was set (explicitly) on one of the parameters targeting the same name.

I'm not sure if I'll have time to put up a PR in the next two days -- I should be able to get it done Monday in the worst case.

[kdeldycke]

The fix in #3079 has been merged upstream and will be available in Click 8.3.1.