[Feature Request] Deeply type-check `set` and `frozenset` containers

I’ve only just noticed that the README says these are only shallowly-checked. I’m very surprised, as these seem like bread-and-butter data structures. Is it accurate to say that whenever we write x: Set[T] (for some specific T) it really just checks against x: Set[Any]?

What’s the roadmap look like for getting this implemented/merged? I’d love to look into how much work a PR for this would be.

[leycec]

Agh! I am being even more confusing than usual. Yes, dict[str] is literally the PEP 585 type hint dict[str]. By dispatching on type hints, Plum is (basically) building out a runtime implementation of the PEP 484 @typing.overload decorator that actually does something useful: multiple dispatch, yo!

Admittedly, I’ve never actually used multiple dispatch before. I just blindly throw around CompSci jargon like I know what I’m talking about. But now that I know about this Plum thing, I’ll be multiple-dispatching everything everywhere regardless of whether I need to. Object-oriented inheritance is so passé. 😉

EDIT: …oh. You were gently pointing out that dict[str] is invalid syntax. Of course, I am now facepalming the poor cat. Let’s pretend I wrote something valid like dict[str, str] or set[str] instead. This never happened, @langfield. </awkward_moments>

[TeamSpen210]

Checking them isn’t the hard part, the hard part is doing it in amortized O(1) time. The way beartype checks an arbitrary data structure without checking time being dependent on the size of the structure is to randomly pick a single element to check each time. That way repeated executions will gradually cover the whole space. But for sets and dicts we cannot sample a random element, at least without iterating through everything before that. Issue #7 has more info on all this.

I wonder if there’s a way to do this via ctypes abuse - it’s going to be implementation-specific regardless, may as well use that.