-
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
feat(backend): condition combinators #5405
feat(backend): condition combinators #5405
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @Udiknedormin. Thanks for your PR. I'm waiting for a kubeflow member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
This PR also addresses the |
"If operator combinator was meant, use & or | instead." | ||
]) | ||
warnings.warn(msg) | ||
return super().__bool__() |
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.
Looks like you didn't assign a parent class to ConditionOperator
?
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.
It's inherited from 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.
The build is failing with these errors, so probably the object didn't inherent correctly
Traceback (most recent call last):
File "/home/prow/go/src/github.com/kubeflow/pipelines/sdk/python/kfp/compiler/v2_compatible_compiler_test.py", line 93, in test_two_step_pipeline
self._assert_compiled_pipeline_equals_golden(
File "/home/prow/go/src/github.com/kubeflow/pipelines/sdk/python/kfp/compiler/v2_compatible_compiler_test.py", line 59, in _assert_compiled_pipeline_equals_golden
skipped 9 lines unfold_more
File "/home/prow/go/src/github.com/kubeflow/pipelines/sdk/python/kfp/dsl/_pipeline_param.py", line 32, in __bool__
return super().__bool__()
AttributeError: 'super' object has no attribute '__bool__
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.
Looks like you're right, so it's not inheritance, but some magic instead. I'll just replace it with True
then. Good catch!
operator = attr.ib(type=str) | ||
operand1 = attr.ib(type=Union['PipelineParam', Any]) | ||
operand2 = attr.ib(type=Union['PipelineParam', 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.
Can we use normal __init__
or typed class variables?
What is the advantage of using attrs over the standard Python typing?
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.
What is the advantage of using attrs
It provides __str__
, __repr__
, __eq__
, __hash__
and lots of other utilities out of the box.
Can we use normal
__init__
Normal __init__
will provide neither of the good stuff mentioned above.
or typed class variables?
We don't use any class variables here, these are all instance variables. Class variables are introduced via ClassVar[T]
.
import warnings | ||
|
||
@attr.s | ||
class ConditionOperator: |
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.
Should we name this BinaryPredicate
?
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.
Sure! I just wanted to change as little as possible, but if you're ok with that --- I'd actually prefer that. Especially considering that UnaryPredicate
would be useful too (e.g. for __not__
).
def __and__(self, other) -> 'ConditionOperator': | ||
return ConditionOperator('&&', self, other) | ||
|
||
def __or__(self, other) -> 'ConditionOperator': |
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.
Can we support not
?
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.
Sure, it would require either:
- ignoring one of the arguments (probably setting it to
None
?), like postfix operators in C++ - creating a separate class
UnaryOperator
(and rename this one toBinaryOperator
) - changing
operand1
andoperand2
into a sequence/list/ordered-iterable of operands
import kfp.dsl as dsl | ||
|
||
|
||
class FlipCoinOp(dsl.ContainerOp): |
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.
We should not directly use ContainerOp
in new code
@kfp.components.create_component_from_func
def flip_coin_op() -> str:
import random
return random.choice(["heads", "tails"])
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.
It's an example based on flip-coin. Should we change flip-coin too then?
file_outputs={'output': '/tmp/output'}) | ||
|
||
|
||
class PrintOp(dsl.ContainerOp): |
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.
We should not directly use ContainerOp
in new code
@kfp.components.create_component_from_func
def print_op(msg: str):
print(msg)
object doesn't implement __bool__, it's some internal magic instead therefore, super().__bool__() cannot be used
@Udiknedormin: The following tests failed, say
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Closing this PR. No activity for more than a year. /close |
@rimolive: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Description of your changes:
Addresses issue #5404.
ConditionOperator
andPipelineParamTuple
intoattr
classes.ConditionOperator
's__bool__
method to produce a warning in case of usingand
oror
on it (as it's probably not what the user intended to do)__and__
and__or__
operators onConditionOperator
, which generate a tree.ConditionOperator
in the compiler.Checklist:
Do you want this pull request (PR) cherry-picked into the current release branch?
Learn more about cherry-picking updates into the release branch.
Please consider cherry-picking this change.