-
-
Notifications
You must be signed in to change notification settings - Fork 901
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 issue #1312: Type (typehint) error when calling db.Model
subclass constructor with parameters
#1321
base: stable
Are you sure you want to change the base?
Conversation
1. Provide a descriptor `ModelGetter` for solving the `db.Model` type from the `db` type dynamically. 2. Add `t.Type[sa_orm.MappedAsDataclass]` to `_FSA_MCT`. 3. Let `SQLAlchemy(...)` annotated by the provided `model_class` type.
db.Model
subclass constructor with parameters
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
…t runtime failure in python3.8.
This comment was marked as off-topic.
This comment was marked as off-topic.
Is there any update on this? I have been searching recently for a fix to avoid having to throw "# type: ignore" all over the code.... |
@lawnchairmeku I think I have already done what I can offer. Hopefully, the dev team will have time to review this. If I find this PR has conflict with the target branch, I will take actions to resolve the conflicts immediately, but currently, its condition is good. This project is maintained by a community, so it may take very long for reviewing such a big update. If you intend to start a new project, I recommend this to you: I felt a little bit regret that I did not choose it for my previous project. |
@lawnchairmeku After viewing your reply, I made a decision to migrate to |
The maintainers of this project are the maintainers of lite as well. Just haven't has a lot of time to look at this with other responsibilities. We also recommend trying lite, it avoids the issues that this extensions customizations can create. |
@davidism Thank you for your suggestions! The lite version works very well to me. Please take your time, I am not intending to expedite your actions. If you find a better solution for this issue, please feel free to reject my PR. |
Fix the typehint inconsistence of
db.relationship(...)
.tox>=4
. Mytox
version is4.12.0
.Checklist:
CHANGES.rst
summarizing the change and linking to the issue... versionchanged::
entries in any relevant code docs.pre-commit
hooks and fix any issues.pytest
andtox
, no tests failed.Appendices
Appendix A: The idea of this PR.
This example shows the core idea how this PR works.
Test(prop: _Mul)
makesprop
as a parameter of its type hint. Then the descriptor will solve the type of the propertyTest().prop
dynamically according to the parameter_Mul
of the parameterized type hintTest[_Mul]
. For example, if a new instance is initialized astest: Test[int]
, thenIntOrStr
will solve the type oftest.prop
asint
.Appendix B: Validate the performance of this PR
This PR only changes the behavior during the static type checking. In other words, at run time, the codes work totally the same as the original version. I made this customization because I think the original codes only have type checking issues but work perfectly at run time. That's why I do not submit any changelogs here, because actually I did not change any functionalities or behaviors at run time.
The following code can be used for testing the performance of the type hints provided by this PR. It works perfected in most cases. However, there are two known cases that the type check shows false negative results. See
test_not_as_expectation
.It seems that the static type checking codes cannot be added to pytest. That's why I do not add more tests for this PR.