-
-
Notifications
You must be signed in to change notification settings - Fork 154
TYP: collections.abc.Callable
#1526
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
TYP: collections.abc.Callable
#1526
Conversation
|
Maybe a little bit of a question but should we obsess with pyright_strict and would it become a requirement in the future? It is known to be quite difficult to mix pandas and pyright strict so wondering if that would cause a heavy burden for future PRs? Open to different views @Dr-Irv @MarcoGorelli |
loicdiridollou
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good thanks @cmp0xff, just want to get inputs about the place of pyright strict in our workflow.
true, but maybe that's the kind of difficulty which PRs like this one take a step towards resolving? |
|
Indeed, |
I don't think we'll ever be able to completely support pyright strict because of things like |
|
i thought (hoped 🤞 ) that #1232 address the |
Possibly. But there are current 1436 "partially unknown" types of errors, and those might be difficult to handle. But those may be due to places where we use |
|
|
|
Okay just wanted to make sure this was a route we wanted to take since there is quite a bit of work to make it happen, thanks @cmp0xff ! |
Towards #1522, which is too big.
collections.abc.Callablehas no default value for the arguments. Replacing all bareCallablewithCallable[..., Any], so thatpyright_strictis happier.