-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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 untyped functions in core/dbt/context/base.py
#8525
Fix untyped functions in core/dbt/context/base.py
#8525
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #8525 +/- ##
==========================================
+ Coverage 84.58% 86.36% +1.77%
==========================================
Files 174 174
Lines 25579 25578 -1
==========================================
+ Hits 21637 22090 +453
+ Misses 3942 3488 -454
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
I'm very confused on how the functions contextmember and contextproperty operate. They are function decorators, and in python function decorators are required to return a callable. However... in cases where the |
909b377
to
4243780
Compare
4243780
to
48c7de0
Compare
In addition to just adding parameter typing and return typing to `BaseContext` functions. We also declared `_context_members_` and `_context_attrs_` as properites of `BaseContext` this was necessary because they're being accessed in the classes functions. However, because they were being indirectly instantiated by the metaclass `ContextMeta`, the properties weren't actually known to exist. By adding declaring the properties on the `BaseContext`, we let mypy know they exist.
… and add typing to them Previously `contextmember` and `contextproperty` were 2-in-1 decorators. This meant they could be invoked either as `@contextmember` or `@contextmember('some_string')`. This was fine until we wanted to return typing to the functions. In the instance where the bare decorator was used (i.e. no `(...)` were present) an object was expected to be returned. However in the instance where parameters were passed on the invocation, a callable was expected to be returned. Putting a union of both in the return type made the invocations complain about each others' return type. To get around this we've dropped the bare invocation as acceptable. The parenthesis are now always required, but passing a string in them is optional.
48c7de0
to
a613ef0
Compare
Out of curiosity is this a different way of approaching the change we reverted here #8306? |
@McKnight-42 I'm not wholly sure, but I don't think so. I could absolutely be wrong about that though. My understanding of issue #8153 is that all numeric values were being forced into floats, and the solution (#8306) was to actually add an |
ah makes sense thanks for clarification @QMalcolm |
resolves #8394
Problem
We have a lot of untyped functions in
core/dbt/context/base.py
this means thatcan't type check untyped functions
warnings appearSolution
ADD TYPES TO ALL THE THINGS 🎉
Checklist