[FEATURE] Literal type support

[alippai]

Support for the literal type (python 3.8 or via typing_extensions) would be nice. Eg.

def get_list(output: Literal["raw", "json", "yaml"] = "raw"):
  if output == "json":
    typer.echo(json.dumps([1, 2, 3]))

The only workarounds (using string or multiple bool flags + validating input) are ugly now.

[tiangolo]

I think you can solve it with an enum.

Here are the docs: https://typer.tiangolo.com/tutorial/parameter-types/enum/

[alippai]

This could work indeed

[tiangolo]

Great! If that answers your question you can then close the issue.

[github-actions]

Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues.

[Aran-Fey]

I don't get why this is closed. Does this mean you won't be adding support for typing.Literal? Or did the bot mess up?

[ghost]

This sounds pretty useful to me.

[arogozhnikov]

Literal is pretty useful, and supported by pydantic for a while.

Certainly vote for adding support. There is a pretty well-written PR too #174.

If that one isn't satisfactory, @tiangolo please state this, because reason for not supporting is unclear

[f4hy]

While things could be rewritten as an enum, it does not play nice with existing typed code which uses typing.Literal to define a set of allowed values. I hope we can revisit this.

[kimothy]

I agree as @f4hy as well. In many cases typing.Literal is a much more elegant solution then using enum.Enum.

[lainisourgod]

@tiangolo I have a case similar to @f4hy. In my ML project I use smth like TargetType = typing.Literal["age", "income", "gender"] to specify which targets I train model for, and use it in dicts ({"age": 40, "income": 11}), keys in exported json-s, and as argument types to functions so I can be sure I won't use unspecified target in my code.

I don't wanna rewrite everything else in enum style, it will be tedious and harder to use.

[woutervh]

Can we reopen this ticket?

Silly bots closing open tickets because they misinterpret a sentence is quite annoying.

[danielgafni]

+1, this would be useful

[Yarden-zamir]

Can we have this reopened maybe? Enums are a different usecase. Yes they function the same in the end but they are ergonomically different. Using an enum is good for when the same slection of choices is used somewhere else too, and using a literal is useful when it's a one time thing and it helps show in a very clear way what options are possible in the same line

def make_cheese(type: CheeseType)

This makes sense for an enum because CheeseType is something that will be useful in more places in the code.

def make_food(for_person: AllPersonsICareAbout)

This makes less sense, because in my case, I don't care about who I can cook for in other places (for now)

def make_food(for_person: Literal['Yarden', 'Bob']):

Either way, even if you disagree, the language evidently does agree, meaning those two are different and are both implemented so the argument that they are the same is not passing. You can argue that they are similar enough which makes it none critical to invest resources in implementing this now. I can agree with that, but if that's the case, reopen the issue and have it in the backlog, maybe someone else will implement it

[samsja]

I could use this as well 🥲

[dorinclisu]

Please reopen.

[Yarden-zamir]

This issue was closed 4 years ago. Maybe it's time for a new issue or fork?

[5j9]

This issue was closed 4 years ago. Maybe it's time for a new issue or fork?

Cyclopts supports this feature, see: https://cyclopts.readthedocs.io/en/latest/rules.html#coercion-rules-literal