Wessel

Hey @hodgespodge! Thanks for opening an issue. :) I believe the ambiguity arises from the following: ```python In [1]: from beartype.door import is_bearable In [2]: is_bearable({"1": "2"}, dict[int, int]) Out[2]:...

@hodgespodge Deep type checking of `dict`s is currently not supported by Beartype, see [this issue](https://github.com/beartype/beartype/issues/246) and [this part of the Beartype docs](https://beartype.readthedocs.io/en/latest/pep/). However, @leycec is working hard on Beartype, and...

Yesss, it is the one and only @leycec! Your tentative schedule of releases sound really promising. I will be looking forward to them very much. :) And thanks for pointing...

Hey @DonkeyKong1! You're right that dispatch interacts a bit strangely with keyword arguments. In particular, arguments which are not given a default value must also be given in non-keyword form....

Hey @astanziola! The design of Plum is heavily inspired by how multiple dispatch works in the Julia programming language. In Julia, keyword arguments are also not considered in the dispatch...

@teffland Currently, there are no plans to dispatch on keyword arguments, but obviously future plans can change. :) I agree that calling a function with named arguments is very common...

Hey @teffland! Apologies for the very slow reply. What you're proposal is in fact already happening, but only for arguments with defaults. That is, ```python def f(x: int, y: int...

@gabrieldemarmiesse could you give an example? I'm not sure that I fully understand this use case.

@gabrieldemarmiesse, I see! If I understand correctly, the idea is to tie argument names to positions, e.g. `x` should always be the first argument and `y` the second, and to...

@gabrieldemarmiesse Right! That sounds even better. I would be fully on board with that. :)