-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
exp show: show metrics that include separator #9819
Changes from 4 commits
32a6974
d91e08c
fff14b6
2e7a254
25ab060
d4600e9
b12f501
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -177,26 +177,29 @@ def _build_rows( | |
) | ||
|
||
|
||
def _sort_column( | ||
def _sort_column( # noqa: C901 | ||
sort_by: str, | ||
metric_names: Mapping[str, Iterable[str]], | ||
param_names: Mapping[str, Iterable[str]], | ||
) -> Tuple[str, str, str]: | ||
path, _, sort_name = sort_by.rpartition(":") | ||
sep = ":" | ||
parts = sort_by.split(sep) | ||
matches: Set[Tuple[str, str, str]] = set() | ||
|
||
if path: | ||
for split_num in range(1, len(parts)): | ||
path = sep.join(parts[:split_num]) | ||
sort_name = sep.join(parts[split_num:]) | ||
if path in metric_names and sort_name in metric_names[path]: | ||
matches.add((path, sort_name, "metrics")) | ||
if path in param_names and sort_name in param_names[path]: | ||
matches.add((path, sort_name, "params")) | ||
else: | ||
if not matches: | ||
for path in metric_names: | ||
if sort_name in metric_names[path]: | ||
matches.add((path, sort_name, "metrics")) | ||
if sort_by in metric_names[path]: | ||
matches.add((path, sort_by, "metrics")) | ||
for path in param_names: | ||
if sort_name in param_names[path]: | ||
matches.add((path, sort_name, "params")) | ||
if sort_by in param_names[path]: | ||
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. Do we want to support it in (in the current fix we are also supporting params in the exp show) 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. I think it's worth discussing, but I figured even this limited fix is better than the current situation. |
||
matches.add((path, sort_by, "params")) | ||
|
||
if len(matches) == 1: | ||
return matches.pop() | ||
|
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 think this would have to go from
range(0, len(parts))
, it has to cover the case where there is no path, and only a metric containing a colonIMO this is also more confusing than requiring escaping, and I think there are still edge cases where the user could have filenames and metric names that overlap and break this kind of behavior
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.
Thanks, fixed.
My thoughts on this PR:
Do you feel it's a blocker and escaping is the only way to go?
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.
Given that the existing behavior is already broken, we can merge this.
But my objection is more that this same problem affects every other command/flag combination that uses
path:metric_or_param
addressing (likeexp run --set-param
and probably alsostage add --params
). I would prefer to only have to fix this once, in a consistent and re-usable way. This PR is just patching over one symptom of a broader underlying problemThere 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.
Also in the same vein, I'm not sure that we actually document that
.
is an invalid character in metric or parameter names, but for all intents and purposes we don't support it because we treat.
as the dictionary level separator in metric/param addressing (even though it is valid to have string keys that contain.
in yaml/json). It would be easier for us to just treat:
the same way and disallow it entirely in metric/param namesThere 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.
Valid points. As mentioned in the issue description, I don't see much harm in doing this unless/until we forbid these characters or have a better solution like escaping, so I'm going to merge but open an issue to discuss whether we should allow it.