-
Notifications
You must be signed in to change notification settings - Fork 102
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
Add more selectable typings #33
Add more selectable typings #33
Conversation
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 PR! I finally had time to test this against our codebase. This PR generates a bunch of new errors that may be false positives. Could you please double check? (And add tests, as usual.)
-
Argument 1 to "limit" of "GenerativeSelect" has incompatible type "Optional[int]"; expected "int"
andArgument 1 to "offset" of "GenerativeSelect" has incompatible type "Optional[int]"; expected "int"
. Could you please double-check thatNone
doesn't work there? -
Argument 1 to "group_by" of "GenerativeSelect" has incompatible type "str"; expected "ClauseElement"
andArgument 1 to "insert" of "TableClause" has incompatible type "Dict[Column[Any], int]"; expected "Optional[Mapping[str, Any]]"
. I noticed that there are some legacy APIs that allowstr
(but they generate warning that recommends wrapping it intext(...)
) andbool
whereClauseElement
is expected. And alsostr
sometimes accepted forColumn
. Could you please check these two (and maybe other) signatures for this? -
Argument 1 to "Select" has incompatible type "AbstractSet[Column[Any]]"; expected "Optional[Sequence[Union[ColumnElement[Any], FromClause]]]"
. Maybe this should beIterable
instead ofSequence
? -
Argument 3 to "Select" has incompatible type "Table"; expected "Optional[Sequence[ClauseElement]]"
. Maybe it accepts a union?
I've addressed the feedback (most were caused by not digging into the underlying code enough), but I'd like to add some tests for what you discovered. Could you give me a few lines of code demonstrating each issue you encountered? |
Sorry for a delay, I just tried this again. There are still three errors in our codebase:
As for tests, the easiest way is to just add dummy tests for affected constructors calls/method calls as I suggested on Gitter. |
(Also an unrelated thought about speeding things up, I think I can manage to review/try PRs twice as large as this one, so if it is OK for you, I think we can try larger sizes.) |
Is it a bug in |
I just looked. |
Oh, sorry, ignore this one. This is a real bug in our codebase found by your new types. :-) |
@bryanforbes what is the status of this PR? Is any input from my side needed? |
@ilevkivskyi No input needed. I just need to put together some tests for the issues you found. I'll try to do that over the weekend or early next week. |
Great, thanks! |
I added a bunch of unit tests testing the issues your found, but I ran into a new issue: t = table('user', column('id'), column('name'), column('description'), column('articles'))
t.insert({column('name', String): 'foo',
'description': 'bar'}) mypy infers the type of the argument to |
Thanks for an update and for good tests! I think the problem you encountered is not easy to fix. It looks like there is a mypy bug (or missing feature) here. Basically mypy's type inference sometimes misfires in presence of unions. I would just remove this particular line in your tests, and open an issue on mypy tracker (maybe also try to find a simpler repro), and then I merge this PR. |
I commented out the failing invocation. I agree that this is either a bug or a missing feature of mypy. A simple repro is as follows: d = {'1': 2, 3: 4}
reveal_type(d) # builtins.dict[builtins.object*, builtins.int*] I have filed an issue at python/mypy#6079. |
OK, thanks! |
No description provided.