DM-36145: Add additional quanta information for pipetask run

[leeskelvin]

Checklist

• ran Jenkins
• added a release note for user-visible changes to doc/changes

[codecov]

Codecov Report

Base: 81.80% // Head: 81.79% // Decreases project coverage by -0.01% ⚠️

Coverage data is based on head (f0489bb) compared to base (33d0155).
Patch coverage: 66.66% of modified lines in pull request are covered.

❗ Current head f0489bb differs from pull request most recent head b770da9. Consider uploading reports for the commit b770da9 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #285      +/-   ##
==========================================
- Coverage   81.80%   81.79%   -0.02%     
==========================================
  Files          56       56              
  Lines        6145     6147       +2     
  Branches     1126     1126              
==========================================
+ Hits         5027     5028       +1     
- Misses        886      887       +1     
  Partials      232      232              

Impacted Files	Coverage Δ
python/lsst/pipe/base/graph/graph.py	81.30% <66.66%> (-0.18%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[taranu]

If it's dict-like, self._taskToQuantumNode.get(taskDef, ()) or similar should work.

[leeskelvin]

I've tried your suggestion, and it does work as intended. With that said, I feel like the syntax here is more explicit about what it's doing, which I prefer. My preference would be to keep it as-is (and similarly below in the new method that's been added), but if you feel strongly otherwise, I'd be happy to change it.

[taranu]

It shouldn't matter in this case because I wouldn't expect the get call to return anything False-but-not-None, but they're not identical. The current form would ignore any Falsey values (literal False, 0, etc.), which I would generally find to be a strange choice if deliberate. Consider x = {'a': 0} followed by if y := x.get('a'): print(y); this prints nothing.

[timj]

I would tend to agree that this code is saying that the result should be a tuple if there is no element in the dict and so .get(x, DEFAULT) is closer to that intent. It's not really saying that tuple should be returned if any of the elements evaluate to false.

[taranu]

It's .get() either way. I'm saying I can't think of a good reason to use dict.get(key) or default instead of dict.get(key, default), unless you really want to change the return type for a particular False-y value like an empty dict to a list?

[timj]

Yes, I was agreeing with you 100% but my phrasing was ambiguous.

[leeskelvin]

Thank you both. Both relevant lines edited as per your recommendation.