-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Mypy: Syntax errors #20157
Comments
@Dreamsorcerer, thanks for the suggestion! Directing it to the right people, so they can address this! |
Thanks for reporting this @Dreamsorcerer (Sam). We are tracking this work as a part of #20083 |
I fixed some of the type annotations in #20084 |
As another suggestion, it would be a good idea to actually setup mypy as a CI check. I can review PRs or answer questions relating to this if help is needed (I've setup several other projects before). |
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage. Issue DetailsBy mistake, we started using the prerelease version 12.9.0b1 of azure-storage-blob in our CI. This resulted in these syntax errors from mypy:
If you check the code at those locations, they are obviously wrong as the number of arguments in the type annotation does not match the number of arguments in the definition. To avoid these mistakes in future, I'd suggest using the common-practice inline annotations, which would make it impossible to make this mistake: def get_modify_conditions(kwargs: Dict[str, object]) -> ModifiedAccessConditions:
|
Broken typing is now released at 12.9.0 |
change the name of a new enumeration in storage's latest api-version (Azure#20157) * change the name of a new enumeration * revert changes in python readme * add directive to mitigate go sdk breaking change Co-authored-by: Chenjie Shi <tadelesh.shi@live.cn>
By mistake, we started using the prerelease version 12.9.0b1 of azure-storage-blob in our CI.
This resulted in these syntax errors from mypy:
If you check the code at those locations, they are obviously wrong as the number of arguments in the type annotation does not match the number of arguments in the definition.
To avoid these mistakes in future, I'd suggest using the common-practice inline annotations, which would make it impossible to make this mistake:
The text was updated successfully, but these errors were encountered: