| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| Expand Up | @@ -2535,6 +2535,94 @@ def meth(x): ... | |
| with self.assertRaises(TypeError): | ||
| isinstance(C(), BadPG) | ||
|
|
||
| def test_protocols_isinstance_properties_and_descriptors(self): | ||
| class C: | ||
| @property | ||
| def attr(self): | ||
| return 42 | ||
|
|
||
| class CustomDescriptor: | ||
| def __get__(self, obj, objtype=None): | ||
| return 42 | ||
|
|
||
| class D: | ||
| attr = CustomDescriptor() | ||
|
|
||
| # Check that properties set on superclasses | ||
| # are still found by the isinstance() logic | ||
| class E(C): ... | ||
| class F(D): ... | ||
|
|
||
| class Empty: ... | ||
|
|
||
| T = TypeVar('T') | ||
|
|
||
| @runtime_checkable | ||
| class P(Protocol): | ||
| @property | ||
| def attr(self): ... | ||
|
|
||
| @runtime_checkable | ||
| class P1(Protocol): | ||
| attr: int | ||
|
|
||
| @runtime_checkable | ||
| class PG(Protocol[T]): | ||
| @property | ||
| def attr(self): ... | ||
|
|
||
| @runtime_checkable | ||
| class PG1(Protocol[T]): | ||
| attr: T | ||
|
|
||
| for protocol_class in P, P1, PG, PG1: | ||
| for klass in C, D, E, F: | ||
| with self.subTest( | ||
| klass=klass.__name__, | ||
| protocol_class=protocol_class.__name__ | ||
| ): | ||
| self.assertIsInstance(klass(), protocol_class) | ||
|
|
||
| with self.subTest(klass="Empty", protocol_class=protocol_class.__name__): | ||
| self.assertNotIsInstance(Empty(), protocol_class) | ||
|
|
||
| class BadP(Protocol): | ||
| @property | ||
| def attr(self): ... | ||
|
|
||
| class BadP1(Protocol): | ||
| attr: int | ||
|
|
||
| class BadPG(Protocol[T]): | ||
| @property | ||
| def attr(self): ... | ||
|
|
||
| class BadPG1(Protocol[T]): | ||
| attr: T | ||
|
|
||
| for obj in PG[T], PG[C], PG1[T], PG1[C], BadP, BadP1, BadPG, BadPG1: | ||
|
Comment thread
Copy link
Copy Markdown
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Qualitynit: these are all protocol classes still; the name 'protocol_class used in the above "good" loop seems much clearer than the name obj
Sorry, something went wrong.
All reactions
Copy link
Copy Markdown
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityNo strong opinion here, but the reason I avoided "protocol_class" for these ones is that the parameterised ones (PG[T], etc) aren't strictly speaking classes anymore — they're generic aliases to protocol classes.
Sorry, something went wrong.
carljm reacted with thumbs up emoji
All reactions
|
||
| for klass in C, D, E, F, Empty: | ||
| with self.subTest(klass=klass.__name__, obj=obj): | ||
| with self.assertRaises(TypeError): | ||
| isinstance(klass(), obj) | ||
|
|
||
| def test_protocols_isinstance_not_fooled_by_custom_dir(self): | ||
| @runtime_checkable | ||
| class HasX(Protocol): | ||
| x: int | ||
|
|
||
| class CustomDirWithX: | ||
| x = 10 | ||
| def __dir__(self): | ||
| return [] | ||
|
|
||
| class CustomDirWithoutX: | ||
| def __dir__(self): | ||
| return ["x"] | ||
|
|
||
| self.assertIsInstance(CustomDirWithX(), HasX) | ||
| self.assertNotIsInstance(CustomDirWithoutX(), HasX) | ||
|
|
||
| def test_protocols_isinstance_py36(self): | ||
| class APoint: | ||
| def __init__(self, x, y, label): | ||
| Expand Down | ||
| Back | FazBrowse Home | New Git URL |
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.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityWhat about side-effects in @property like raise ValueError? Should we test this case?
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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.
Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityWe should test this case, definitely! But the behaviour for this case may be about to change if any of the patches discussed in python/typing#1363 is implemented (and the consensus seems to be that we should implement one of those patches). If so, we should add the tests in the same PR as we change the behaviour.
Whether or not we decide to change the behaviour around properties that have side effects, I'd prefer to add those tests in a separate PR, so that this PR is solely focussed on adding tests for uncontroversial behaviour.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.