Skip to content
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

question: possible to make typecheck more strict? #3130

Open
GliderGeek opened this issue Sep 4, 2019 · 4 comments

Comments

@GliderGeek
Copy link

commented Sep 4, 2019

first off thanks a lot for this amazing tool!
if this is not the right place to ask a question, my apologies. i have looked for answers in the documentation / other issues but couldn't find a conclusive answer.

Cython compiled code sometimes raises TypeErrors when builtin typehints are used and not respected by the caller of the function. This is something i really like, but i wander why certain builtins do not raise these errors?

The following table gives an (incomplete) overview of frequently used builtins:

typehint input TypeError?
int str n
int list n
str int y
float str y
float bool n
dict str y
set str y
set dict y
list str y
bool str n

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 Dict, Union, Optional and Classes.

Source for creating table:
typehints_cython.zip
execute with command:
python3 setup.py build_ext --inplace && python3 -c "from type_checking import check; check()"

@GliderGeek

This comment has been minimized.

Copy link
Author

commented Sep 4, 2019

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 TypeError is raised whenever the function is called with a wrong argument type.

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.

@GliderGeek GliderGeek changed the title question: possible to stricten typecheck? question: possible to make typecheck more strict? Sep 4, 2019

@scoder

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2019

We currently ignore int in type hints, because a) it's not a C int, b) it's ambiguous in Python 2 because users normally mean "int or long" instead, and c) Python int has no real advantages for the compiler.

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:

  • add a new int_type to the bottom of Builtin.py
  • make sure that we correctly analyse the int type in annotations and map it to Builtin.int_type
  • make sure (and this might be the tricky part) that there is no confusion with the C int type, i.e. that the Python int type is really only read from annotations and not from cdef int … etc.
  • make sure that the correct type check is generated

This requires a couple of new test modules, including Cython syntax, a pure Python module, and maybe also the different language levels.

@GliderGeek

This comment has been minimized.

Copy link
Author

commented Sep 5, 2019

thanks, would you say this might be expanded to a complete typecheck in the future? (not only int, but all builtins and typing.Dict, own types etc...)

i am not really familiar with the source of Cython yet, but i will try

@scoder

This comment has been minimized.

Copy link
Contributor

commented Sep 6, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.