Activity

1. tleonhardt

   added

   enhancement

   on Jun 10, 2026
2. KelvinChung2000 commented on Jun 10, 2026

   

   KelvinChung2000

   on Jun 10, 2026

   Contributor

   More actions

   I will add support for this use case. For now, I will allow only a mix of Enum and Literal, since they are "constant-like". For most other options, I think it will be very ambiguous to tell what it should resolve to.
3. tleonhardt

   assigned

   KelvinChung2000

   on Jun 11, 2026
4. KelvinChung2000 commented on Jun 15, 2026

   

   KelvinChung2000

   on Jun 15, 2026

   Contributor

   More actions

   After some thinking, I am not sure if the use case actually makes sense, or if it is better to be done via a combination of the existing construct.

   • EnumA | EnumB: I cannot think of a case where you would want to do this. If A and B are relevant inputs, you will likely put them into a single enum.
   • EnumA | Literal["auto"]: this use case makes sense, since you might want an option that is not part of the enum, but you will still want a value. In this use case, would using the _missing_ method to set a default be a better idea?
   • EnumA | Literal["autoA", ...]: this basically falls back to using _missing_ again, since likely any of the literal options will go to

   I will add documentation and update the code path. Since right now, it will only trigger a hard error. I will add a new option that takes in an unknown member and let it trigger the _missing_ on the enum.
5. neoniobium commented on Jun 15, 2026

   

   neoniobium

   on Jun 15, 2026

   ContributorAuthor

   More actions

   I use EnumA, EnumB as well as EnumA | EnumB as possible arguments for different functions.

   class App(Cmd):
   
       @with_annotated
       def do_A(a: EnumA) -> None:
           ...
   
       @with_annotated
       def do_B(b: EnumA) -> None:
           ...
   
       @with_annotated
       def do_AB(ab: EnumA | EnumB) -> None:
           ...
6. tleonhardt

   closed this as completedin #1694on Jun 16, 2026