dstandish commented on a change in pull request #20184:
URL: https://github.com/apache/airflow/pull/20184#discussion_r766230039
##########
File path: airflow/utils/helpers.py
##########
@@ -244,3 +244,18 @@ def build_airflow_url_with_query(query: Dict[str, Any]) ->
str:
view = conf.get('webserver', 'dag_default_view').lower()
url = url_for(f"Airflow.{view}")
return f"{url}?{parse.urlencode(query)}"
+
+
+def exactly_one(*args):
+ """
+ Returns True if exactly one of *args is "truthy", and False otherwise.
+ :param args:
+ :return:
+ """
+ has_one = False
+ for arg in args:
+ if arg and has_one:
+ return False
+ elif arg:
+ has_one = True
+ return has_one
Review comment:
> That would work. In that case though, I’d make some of the existing
changes more explicit e.g. exactly_one(execution_date is not None, run_id is
not None)
I went with `exactly_one(execution_date, run_id)` because AFAIK those values
obey truthy evaluation. Are you suggesting that we do `is not None` because we
should never do truthy evaluation? Or because in this particular case there is
a reason not to? When it was XOR there was a reason (namely because XOR
doesn't handle truthy), but seems here it should be OK, and as you pointed out
it's less verbose -- wdyt?
> that’s a bit verbose to me though, so parametrising exactly_one should
still be considered IMO
I did explore the idea above, and arrived at the feeling that it wasn't
worth it. But if you feel strongly we should parameterize please say so and
perhaps propose a manner. It doesn't really cost too much to parameterize just
makes it a little more complicated to understand the behavior.
> On second thought, this falsy-none problem may be an unnecessary pitfall
in the first place, indicating we should build safeguards in exactly_one in the
first place.
can you clarify?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
