-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Surprising issubclass result #21
Comments
Now, the following return true:
But this is false again:
This is surprising in some ways. First, But the other thing is that covariance should matter when we are talking about return types from a function, but for a stand-alone type comparison it should not, no? |
Using a covariant typevar as value for an invariant type parameter seems invalid to me. This is currently undefined behavior, but I suppose
should behave like the |
Please don't. :-) This is a workaround I am currently using. The issue with Moreover, one other reason why this should not be an error is because you might want to signal that a particular function is not changing the |
No worries, I want pytypes to be convenient. It is already less strict than PEP 484 in case of mutable maps, see pytypes.covariant_Mapping I still think it's fine to use
Hmmm I don't find an example there where they simply use Anyway, for me it seems okay to let pytypes accept your version as well. |
I was thinking about this section:
So if function does not mutate the argument, argument can act covariantly. But you are right that in 483 they discuss how one should create an immutable container and how:
|
The following works though:
|
Yes, that's exactly the variant I'd consider valid and I think I took care to support. There are also tests for this. |
Playing with this a bit more.
I would assume those to be true? The issue comes from |
Maybe the ellipsis notation for tuple is not yet properly supported. (Maybe not at all, I'd have to look into the code...) |
It would be very helpful if you could write your experiments in a form that can be used as a test. |
Oh, sorry. Those examples above are self-contained. You can just copy-paste them into a Python interpreter and they should exercise the error. I thought this is enough to wrap them into tests. What would you prefer instead? A PR adding this as a test? Or some other syntax here in the issue? |
Yes, ideally a PR. Turning experiments into test often involves some subtle additional work, yet usually rather trivial. E.g. finding the right place in the messy test suite (yes we need a better test system,help welcome), choosing the right name, add eventually both a Python 2 and 3 version. While turning it into a test one sometimes finds that some additional cases should be covered as well. |
I just noticed that |
I think the ellipsis-related issues are fixed now as of 774e4be. Can you confirm? Still, a tests-PR would be nice. |
So I think one issue here is that Python standard >>> type_util._issubclass(typing.List[float], typing.List)
False
>>> issubclass(typing.List[float], typing.List)
True |
Hmm, this is due to the invariance of
However these can only make checking even stricter, e.g. disallow parameterless . |
Yes, I understand where is coming from. It is just surprising. I was hoping to just replace all isinstance with pytypes. It seems I might want to do or between both. :-) If any says true, then it is an instance. :-) Not sure what could be changed here to make this different, while keeping the proper type checking. It is just in practice surprising when you just want to see that something is a subclass or instance. Maybe we could differentiate between explicit |
Hmm, I actually differentiated between |
IIRC regarding |
Also see #34 (comment). |
A very good point and interesting point about runtime vs. static time checking. At runtime you can really know precisely what the value is. So some constraints might not be reasonable. Thanks for this insight. |
Skimmed through PEP 484 again and found this note:
However this does not answer how to handle the case that a function really intends typesafe write-access to a list object passed in as parameter. Maybe the typechecked-decorator should offer some feature to configure this per-function additional to a global flag. |
We got hit again by this. Really hard to debug.
There are not options to configure that |
The only viable option at this moment is to type it using Sequence. If you need a writable type maybe Union[List, Sequence] could work...? |
What exactly do you think PR should do? How you imagine a change to support this? |
You could implement a special case for list in similar fashion as is done for dict already. |
Why the following returns false?
Isn't this the same as
type_util._issubclass(typing.List[float], typing.List[typing.Any])
? And thenfloat
is an instance oftyping.Any
? But this is false as well:The text was updated successfully, but these errors were encountered: