-
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
Implement ADR 0002 (remove special handling of Optional and Union) #158
Conversation
bf26904
to
f55e818
Compare
f55e818
to
80b410b
Compare
@@ -149,7 +149,7 @@ def _find_nodes_in_paths(graph: Graph, end: Key) -> List[Key]: | |||
|
|||
|
|||
def _is_multiple_keys( | |||
keys: type | Iterable[type] | Item[T], | |||
keys: type | Iterable[type] | Item[T] | 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.
Isn't this equivalent to keys: Any
now? Why did you add 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.
Yes, I could not get it to work otherwise. I thought listing the others still serves as an expression of intent?
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.
Maybe. So did it not work with Any
? From what I understand that is preferred over 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.
No, I mean I failed to find another more concrete type hint that works. Any
would work.
src/sciline/pipeline.py
Outdated
@@ -793,7 +752,13 @@ def compute(self, tp: Iterable[Type[T]], **kwargs: Any) -> Dict[Type[T], T]: | |||
def compute(self, tp: Item[T], **kwargs: Any) -> T: | |||
... | |||
|
|||
def compute(self, tp: type | Iterable[type] | Item[T], **kwargs: Any) -> Any: | |||
@overload | |||
def compute(self, tp: object, **kwargs: Any) -> Any: |
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.
Similar to above, this is equivalent to
def compute(self, tp: object, **kwargs: Any) -> Any: | |
def compute(self, tp: Any, **kwargs: Any) -> Any: |
if I'm not mistaken.
Does mypy use the specialised overloads where possible or does it always fall back to Any
?
tests/pipeline_with_optional_test.py
Outdated
|
||
|
||
def test_union_with_none_can_be_used_instead_of_Optional() -> None: | ||
def test_Union_and_optional_are_distinct() -> None: |
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 don't think Union[T, None]
and Optional[T]
should be treated differently.
But this test doesn't actually seem to have anything to do with Optional
. It just tests different argument orders.
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 don't think Union[T, None] and Optional[T] should be treated differently.
Then we would need to add special-case handling.
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.
Ah, now I think I understand what you want to test here. But there are no optionals in the test, only unions.
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.
Good catch, fixed I think!
We should probably change sciline/src/sciline/pipeline.py Line 358 in 5a8bdd9
Optional[Dict[Any, Any]] maybe with a comment about the weird behaviour of what is a type vs type hint?
|
I am thinking now that we should remove the |
Implement ADR 0001: Remove isinstance checks when setting params
While
Pipeline
will be re-implemented, I nevertheless made this change, since it allows for updating units tests with new expected behavior, which will make the re-implementation easier/smaller (will pass the same unit tests), decoupling the behavior change from the re-implementation.