Open cromachina opened 1 month ago
So I found that the problem is that the type checking is simply not complete, and I think if you want complete type checking in pyrsistent, then you should probably use some other type checking library, as python's builtin type checking seems inadequate for this. For example, even if you add separate instance checks for types.GenericAlias
or types.UnionType
, the builtin functions isinstance
and issubclass
will fail if the checked object is types.GenericAlias
: https://docs.python.org/3/library/stdtypes.html#types-genericalias
The builtin functions isinstance() and issubclass() do not accept GenericAlias types for their second argument:
So you have to create a bunch of cases to handle all of these type-like objects which are not actually type
s.
However, I think the solution should be to allow types to be specified how the user wants, with the declarations that python already allows (like using a union str | int
instead of a list [str, int]
to specify multiple types) and then have pyrsistent do not do type checking at all of its own. That way we can still benefit from having things like an IDE working nicely (which is what I think most people use type annotations in python for) and use other tools like mypy
if we really want to make sure all of the types unify statically.
If for some reason the type checking must remain, then I think it should be able to be disabled by the user (because it's incomplete and produces errors like above).
Similar type checking woes mentioned here: https://github.com/tobgu/pyrsistent/issues/181
Seems like I can bypass the library's type checking by putting my type right on the variable instead, so that solves my particular issue.
from pyrsistent import *
tuple_type = tuple[int, int]
class Test(PClass):
x:tuple_type = field()
Specifying a tuple type for a field seems to break pyrsistent's type checker.
Pyrsistent version 0.20.0 Python 3.12 Linux (NixOS)
Minimal example
test.py
:Load the module:
Output: