-
-
Notifications
You must be signed in to change notification settings - Fork 450
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
Improve typing in template registry #1904
base: master
Are you sure you want to change the base?
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.
I'm fine with adding the tests, since e.g. the decorators aren't trivial. But I'd say we should bundle them under the same test, some "decorator test".
Mainly as the suite gets slowed down quite a bit with multiple tests.
Will do. I'll also try to add some comments in the stubs, so that it's easier to reason about which overload matches to which use case |
Assigned to @flaeppe. If you don't want to lead the review here, feel free to unassign yourself. |
Thinking again about this, maybe this would things a bit confusing? We would end up with tests of the same module in a separate location. But if still think we should do it this way, I can work on another PR moving every decorator tests, once this one gets merged (will makes things easier to review) |
Comments taken from the Django source code
I meant gathering the newly added tests in this PR under the same test case. e.g.
If you like to refactor existing tests in a separate PR later on, that's fine too |
Fixes #1903