-
Notifications
You must be signed in to change notification settings - Fork 2
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
Switch to functools.cached_properties (#1796) #1843
Conversation
4f6ba37
to
2421f66
Compare
Codecov Report
@@ Coverage Diff @@
## develop #1843 +/- ##
===========================================
- Coverage 83.80% 83.79% -0.01%
===========================================
Files 110 110
Lines 10523 10518 -5
===========================================
- Hits 8819 8814 -5
Misses 1704 1704
Continue to review full report at Codecov.
|
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.
LGTM.
src/azul/objects.py
Outdated
@@ -64,3 +64,17 @@ def __new__(_cls, *args, **kwargs): | |||
return _self | |||
|
|||
cls.__new__ = __new__ | |||
|
|||
|
|||
# Vendored from boltons==19.3.0 |
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 would call this theft, not vendoring.
# Vendored from boltons==19.3.0 | |
# Stolen from boltons==19.3.0 |
src/azul/objects.py
Outdated
|
||
|
||
# Vendored from boltons==19.3.0 | ||
class classproperty(object): |
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.
Does PyCharm infer the return type correctly with this?
Does this technique have any advantages?
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.
Does PyCharm infer the return type correctly with this?
No, not for my test:
class C:
@classproperty
def foo(cls) -> int:
return 42
c = "a" + C.foo
d = "a" + 42
Does this technique have any advantages?
PyCharm does not correctly infer types with this form either. Since this form requires two decorators, I think it is inferior. Also the two decorators raise a different, "incompatible decorator" warning in pycharm.
This implementation is functionally the same as the boltons one, but with better type annotations. Even though the type annotations don't allow inference with PyCharm, I'll steal this one instead.
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.
The main reason we switch to functools.cached_property is to enable PyCharm type inference.
I think we should not encourage the use of @classproperty
since there is no implementation that we know of that allows PyCharm type inference of the return type. For that reason, I think we should completely remove the decorator and eliminate the one use in health.py
.
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.
645bc2c
to
378dce2
Compare
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.
Clean work.
378dce2
to
22d4171
Compare
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 guess I have to take that back. IT fails.
22d4171
to
91745a9
Compare
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.
91745a9
to
9a24886
Compare
Bumping review count for that reason. |
No description provided.