29

How can I get the literal value out of a Literal[] from typing?

from typing import Literal, Union

Add = Literal['add']
Multiply = Literal['mul']
Action = Union[Add,Multiply]

def do(a: Action):
    if a == Add:
        print("Adding!")
    elif a == Multiply:
        print("Multiplying!")
    else:
        raise ValueError

do('add')

The code above type checks since 'add' is of type Literal['add'], but at runtime, it raises a ValueError since the string 'add' is not the same as typing.Literal['add'].

How can I, at runtime, reuse the literals that I defined at type level?

LudvigH
  • 3,662
  • 5
  • 31
  • 49
  • Isn't `Literal` just a hack for the specific use case of type annotations though? Why would you not simply use the string `'add'` here? – tripleee Dec 03 '19 at 19:28
  • With the code above, a static analyzer can tell me that exactly the strings `'add'` and `'mul'` are the allowed parameter values to `do`. Compare with example `AllModes` in [PEP-586](https://www.python.org/dev/peps/pep-0586/). I don't think I could do that so easily with just the strings. – LudvigH Dec 03 '19 at 19:34
  • But a `Literal` is not a value, it is a type constraint which permits a set of values. In your example, `Literal['add', 'mul']` would accept both of these values, and there is obviously no way from the constraint alone to know which of these the it is going to be passed, if indeed it is going to be passed a valid literal at all, or anything whatsoever. – tripleee Dec 03 '19 at 19:39
  • Yes. But I want to make a `if..elif..` statement to check what value was passed, and since I think it is good practice to not have a string written at several place, I would like to not write `'add'`, but rather `Add.value` or something similar. A similar effect is accomplished with enums, of course, but means that the user of `do` would have to import the specific enum to pass parameters. – LudvigH Dec 03 '19 at 20:30
  • I can see that this seems to be what you want, but I don't understand why you insist on this design. A dict of string: function would seem to be a more traditional as well as more workable design. If you want to create a literal out of the dictionary's keys, that will then be completely trivial. – tripleee Dec 04 '19 at 05:50
  • So in summary, it is impossible to get the value out of the typing.Literal at runtime, and your recommendation is to type the same string literal at two places: in dict keys and in the typing.Literal? – LudvigH Dec 04 '19 at 06:25
  • `Literal[ops.keys()]` doesn't require any retyping. I haven't investigated whether it is in fact impossible; again, I would recommend either clarifying why you think it is useful, or trying a different approach. – tripleee Dec 04 '19 at 06:26
  • PEP-586: Literal may be parameterized with literal ints, byte and unicode strings, bools, Enum values and None. .... The following parameters are intentionally disallowed by design: Arbitrary expressions like Literal[3 + 4] or Literal["foo".replace("o", "b")]. ....so that won't work, by what I understand. – LudvigH Dec 04 '19 at 06:32
  • Works here, in the sense that I can type that in without errors, though I can imagine it might throw off a lexical analyzer. – tripleee Dec 04 '19 at 06:35
  • 1
    `myliteral.__args__` contains the args used to initialize it, so I suppose you could dig them out from there. – tripleee Dec 04 '19 at 06:37
  • Would you like to hint at that in an answer, so I can mark it accepted? I just found the `typing.get_args` and `typing.get_origin`, and they might help a little bit. The conclusion still seems to hold: there is no good way to do this i python at the moment. – LudvigH Dec 04 '19 at 07:15

2 Answers2

39

The typing module provides a function get_args which retrieves the arguments with which your Literal was initialized.

>>> from typing import Literal, get_args
>>> l = Literal['add', 'mul']
>>> get_args(l)
('add', 'mul')

However, I don't think you gain anything by using a Literal for what you propose. What would make more sense to me is to use the strings themselves, and then maybe define a Literal for the very strict purpose of validating that arguments belong to this set of strings.

>>> def my_multiply(*args):
...    print("Multiplying {0}!".format(args))
...
>>> def my_add(*args):
...    print("Adding {0}!".format(args))
...
>>> op = {'mul': my_multiply, 'add': my_add}
>>> def do(action: Literal[list(op.keys())]):
...    return op[action]

Remember, a type annotation is essentially a specialized type definition, not a value. It restricts which values are allowed to pass through, but by itself it merely implements a constraint -- a filter which rejects values which you don't want to allow. And as illustrated above, its argument is a set of allowed values, so the constraint alone merely specifies which values it will accept, but the actual value only comes when you concretely use it to validate a value.

tripleee
  • 175,061
  • 34
  • 275
  • 318
  • 1
    Is that `Litera[list...]` valid Python? mypy gives me `error: Invalid type: Literal[...] cannot contain arbitrary expressions` – huyz Dec 05 '20 at 21:27
  • The `get_args` approach won't work out of the box if one combined multiple literals like `Literal[Literal[Literal[1, 2, 3], "foo"], 5, None]` (source: [PEP 586](https://www.python.org/dev/peps/pep-0586/)). For that, one needs to call `get_args` multiple times – Intrastellar Explorer Jan 12 '21 at 01:43
  • 1
    @huyz I guess I didn't test at the time, and you seem to be right; neither `Literal[lst]` nor `Literal[*lst]` works for me in Python 3.8.2. – tripleee Jan 12 '21 at 05:34
  • 7
    Dynamic literal types are not allowed by the python standard https://www.python.org/dev/peps/pep-0586/#illegal-parameters-for-literal-at-type-check-time – Benjamin Sep 16 '21 at 19:50
-1

I guess that the desire to get the value from the type is to avoid code duplication, and enable broader refactors. But let's think about it a second...

Let's consider code duplication. We don't want to have to write the same literal value twice. But here's the thing, we're going to have to write down something twice, either the type or the literal, so why not the literal?

Let's consider enabling refactors. In this case we're worried that if we change the literal value of the type then code using the existing value will no longer work, it would be nice if we could change them all at once. Notice that the problem solved by the type-checker is adjacent to this one: when you change that value it will warn you everywhere that that value is no longer valid. In this case you can opt to use an Enum to put the literal value inside the Literal type:

from typing import Literal, overload
from enum import Enum

class E(Enum):
    opt1 = 'opt1'
    opt2 = 'opt2'

@overload
def f(x: Literal[E.opt1]) -> str:
    ...

@overload
def f(x: Literal[E.opt2]) -> int:
    ...

def f(x: E):
    if x == E.opt1:
        return 'got 0'
    elif x == E.opt2:
        return 123
    raise ValueError(x)

a = f(E.opt1)
b = f(E.opt2)

reveal_type(a)
reveal_type(b)

# > mypy .\tmp.py
# tmp.py:28: note: Revealed type is "builtins.str"
# tmp.py:29: note: Revealed type is "builtins.int"
# Success: no issues found in 1 source file

Now when I want to change the "value" of E.opt1 no one else even cares, and when I want to change the "name" of E.opt1 to E.opt11 a refactoring tool will do it everywhere for me. The "main problem" with this is that it will require users to use the Enum, when the whole point was trying to provide a convenient, value-based but type-safe, interface, right? Consider the following, enum-less code:

from typing import Literal, overload, get_args
from enum import Enum

TOpt1 = Literal['opt1']

@overload
def f(x: TOpt1) -> str:
    ...

@overload
def f(x: Literal['opt2']) -> int:
    ...

def f(x):
    if x == get_args(TOpt1):
        return 'got 0'
    elif x == 'opt2':
        return 123
    raise ValueError(x)

a = f('opt1')
b = f('opt2')

reveal_type(a)
reveal_type(b)

# > mypy .\tmp.py
# tmp.py:24: note: Revealed type is "builtins.str"
# tmp.py:25: note: Revealed type is "builtins.int"

I put both styles of checking the value of the argument in there: def f(x: TOpt1) and if x == get_args(TOpt1) vs def f(x: Literal['opt2']) and elif x == 'opt2'. While the first style is "better" in some abstract sense, I would not write it that way unless TOpt1 appears in multiple places (multiple overloads, or different functions). If it's just to be used in the one function for the one overload then I absolutely would just use the values directly and not bother with get_args and defining type aliases, because in the actual definition of f I would much rather look at a value than wonder about a type-argument.

Nathan Chappell
  • 2,099
  • 18
  • 21