Replies: 1 comment 2 replies
-
Could you provide a minimal, complete code sample that demonstrates what you're seeing and what you would expect to see? |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
What I'm trying to do:
In a code base I'm working on, there are several places where I'm using a
Mapping
subclass in a non-standard way, and I'm implementing the typing related to it using a protocol. Basically, there is some relation between the types of the key and the value, but instead of applying at the mapping level, it's between each key-value pair.I'm representing these using non-generic protocols that have methods something like:
or
So, you could index the first with a
Label[str]
to get astr
, or, with the same object, aLabel[int]
to get anint
.(The values get in there using similarly-written
set()
methods; the actual runtime type is a PMap from pyrsistent.)(
Label
is an internal type that's right now basically like a generic newtype around object.)Anyway, because I need several different relationships between key and value in different contexts, I currently have a bunch of protocol classes that express very similar boilerplate. It would be nice to be able to abstract over this somehow, so I just need to define the wrapper once, and can then just specialize it somehow.
After seeing someone have a similar issue in the gitter channel, I came up with something that would solve the problem, if it worked. With the samples above, it would look something like this:
I wrote that all up without testing it, but if you substitute in the obvious values for the stuff I left implicit, that code all passes type-checking if I didn't make a mistake.
My question, which I already asked in gitter but I didn't get many responses, is whether using those protocols down there should work, from a typing perspective.
When I tried out similar code in Mypy and Pyright, when I get as far as something like
direct_map[int_label]
, it didn't unify the argument to__getitem__
with the argument to the protocol's__call__
method, with the result that there's a type error because of something like,Label[int]
isn'tLabel[T]
, and the return value that comes back isT`-1
.(Precise details may be off because I'm trying to bridge the gap between the simplified code I tried, and my actual use case, but I don't expect my use case to work if the simplified code doesn't.)
Ultimately, what I'm asking is, is this a bug (presumably against type checkers), or a feature request?
EDIT: full, simplified example
Beta Was this translation helpful? Give feedback.
All reactions