Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
question: possible to make typecheck more strict? #3130
first off thanks a lot for this amazing tool!
Cython compiled code sometimes raises
The following table gives an (incomplete) overview of frequently used builtins:
Is there a complete list somewhere in which i can find which typehints are enforced?
Is there maybe a way to make these checks more strict and throw a TypeError in all above cases?
I would be even nicer is this could also be done with
Source for creating table:
A bit of context: i am using Cython for a distributed library and want the functions with type hints to fail fast, meaning that a
There are some solutions (https://github.com/Stewori/pytypes, https://github.com/agronholm/typeguard) which check these at runtime, but i need to change the source and cython does this out of the box, so i was wondering whether that functionality could be expanded.
We currently ignore
However, your use case seems reasonable and I agree that at least issuing a type check would be right when the user already put a type annotation into the signature. When we drop Python 2 support in Cython 3.1, this should become a feature. With some tweaking, we might be able to generate a correct int/long type check already in Py2.
What needs to be done:
This requires a couple of new test modules, including Cython syntax, a pure Python module, and maybe also the different language levels.
would you say this might be expanded to a complete typecheck in the future?
Actually, "int" is the special case amongst the builtins here, because it was previously ignored. Regarding Dict etc., you can't really do a runtime type check for them, definitely not for their key-value types, but also because they allow subtypes with arbitrarily differing behaviour. So there is no use in these annotations for the compiler, no better assumptions that they would allow it to make. We could start showing things down a little by doing these type checks at runtime, but it feels like that counters the intention of using an optimising compiler. This is not a strict no, I'm just saying that this is currently very low on our list.