-
-
Notifications
You must be signed in to change notification settings - Fork 946
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
fix(typing): use proper type for SinkCallable **kwargs #2411
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2411 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 64 64
Lines 7726 7726
Branches 1071 1071
=========================================
Hits 7726 7726 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
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.
Hi,
The proposed typing is wrong. kwargs
are not typed as dict.
Also when can you have none as the value?
8a757d6
to
c69325c
Compare
Oh right, that kwargs thing not being a dict is one of those typing gotchas. Anyway, to answer your question, kwargs is constructed using
I'll give it another thought - what I'd like is being able to have my functions implement SinkCallable with a call signature
but mypy and other type checkers cannot infer that **kwargs is going to be empty in those cases so there will be a type mismatch. I guess for now I'll have to write it as
which somewhat nullifies the elegance of passing these things as keyword arguments :( Long term I can imagine having |
c69325c
to
c4af605
Compare
understood! regarding the call signature for sink, maybe we can use |
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.
Thanks for this improvement @jap, yes, the values may be None
in the case of optional unmatched regex groups.
oh I wanted to try overload in this branch, but I guess we can do a follow on change for it |
Aha I thought you were planning a follow-up anyway since you approved 😅 |
No description provided.