[FeatReq] support for literal types

[PabloLION]

This seems to be mentioned in the discuss of #53 (comment)
While I was trying to dispatch with typing.Literal[True] it fails.
Can we add this functionality?
TIA.

[wesselb]

Hey @PabloLION! I'm planning a rework of the internals of the package, which should make support for typing.Literal[True] simple.

[PhilipVinc]

@wesselb we already support something like literal types since #18 , and they are called Val types.

It should be trivial to map 1 to 1 plum's Val to typing Literal s and support this as of now.

[PabloLION]

@PhilipVinc I didn't knew this after reading the docs😂 and I searched the docs too. Maybe add a reference of "Literal" to the page https://wesselb.github.io/plum/api.html#plum.parametric.Val to for searching index?

For me personally,

1. I didn't test the Val type and not sure if they does the same work
2. Using the same word Literal as python internal is more intuitive

[wesselb]

@PhilipVinc, Val is indeed similar, but I believe not exactly what @PabloLION is looking for. I think this is the difference:

@dispatch
def f(x: Val[True]):
    print("Got the literal `True`!")

Then this is the behaviour:

>>> f(Val(True))
Got the literal `True`!

>>> f(Val("other literal"))
NotFoundLookupError: For function "f", signature Signature(plum.parametric.Val[other literal]) could not be resolved.

However, for a function,

@dispatch
def f(x: Literal[True]):
    ...

the wrapping in Val shouldn't be necessary. That is, f(True) instead of f(Val(True))/f(Literal(True)) should work.

With the current design, which assumes that all information necessary for dispatch is contained in the types of the arguments, type_of would have to do a lot more work. I therefore think that @tbsexton's proposal is a good way of getting still getting the desired behaviour.