Go the other way around, and build VALID_ARGUMENTS from Argument:

Argument = typing.Literal['foo', 'bar']
VALID_ARGUMENTS: typing.Tuple[Argument, ...] = typing.get_args(Argument)

I've used a tuple for VALID_ARGUMENTS here, but if for some reason you really prefer a list, you can get one:

VALID_ARGUMENTS: typing.List[Argument] = list(typing.get_args(Argument))

It's possible at runtime to build Argument from VALID_ARGUMENTS, but doing so is incompatible with static analysis, which is the primary use case of type annotations.

Doing so is also considered semantically invalid - the spec forbids parameterizing Literal with dynamically computed parameters. The runtime implementation simply doesn't have the information it would need to validate this. Building VALID_ARGUMENTS from Argument is the way to go.

list(...) is not interchangeable with [...]. You can wrap square brackets around things to get nested lists, but wrapping things in list() doesn't have the same effect.

• When you write [[]] you get a list with a single element. That element is [].

• When you write list([]) the list constructor takes an iterable and creates a list with the same elements. If you wrote list(['foo', 'bar']) the result would be ['foo', 'bar']. Writing list([]) yields [].

  This form is more useful when you pass iterables that aren't lists. Other examples:

  list('abc') == ['a', 'b', 'c']         # strings are iterables over their characters
  list(('foo', 'bar')) == ['foo', 'bar'] # tuple
  list({'foo', 'bar'}) == ['foo', 'bar'] # set; could get ['bar', 'foo'] instead
  

• list(list()) is equivalent to list([]). And we've seen that's in turn equivalent to [].

Stay away from [[]] * n when creating a multidimensional list. It will create a list with n references to the same list object and will bite you when you try to modify the internal lists. It's a common mistake that everyone makes. Use this instead, which will create a separate empty list for each slot:

[[] for i in range(n)]

Further reading:

• How to create a multi-dimensional list
• List of lists changes reflected across sublists unexpectedly

The difference between

my_list = list()

and

my_list = []

is that list requires a namespace lookup, first in the module level globals, then in the builtins.

On the other hand, [] is a list literal and is parsed as creating a new list from the language, which doesn't require any name lookups. So the literal is faster on object creation.

Otherwise, they are both the same, for empty lists.

The same analogously applies to dict() and {}.

(Slightly beyond the scope of the question, but the difference, as constructors of non-empty lists, is that list() takes an iterable to construct the list, and [] constructs the list with only the objects with which you create it, usually literals.)