Hi Russell Owen,

Please review these changes. The changes in each package are individually small, but there are quite a few of them.

Overall this looks excellent, and it was clearly a heroic effort.

However, I have one serious concern: some tests in pipe_tasks are being skipped because BaseRecord.get isn't doing the right thing. That suggests the current wrapping is inadequate and should be fixed. The skip message suggests waiting for DM-8716, but unless Jim Bosch agrees with that and plans to merge that soon, I think it would be better to just fix afw without the extra benefits of DM-8716.

I did indeed advise Krzysztof Findeisen to defer fixing problems with BaseRecord.get/set until DM-8716, but if that means we're not testing much of anything in pipe_base as a result, that implies we also won't really be able to run any full integration tests until DM-8716 is complete, and that might cause enough problems with the timeline that we would be better off finding a workaround. But I still don't want us to put much effort into cleaning up BaseRecord.get/set as they stand now, because they're going to be completely blown away in DM-8716.

Looking back at the original Slack conversation, it seems the main problem was BaseRecord.getL not being present - if that is the only kind of problem we're seeing here, the best workaround may be to replace getL with get (and likewise for other suffixes) in the Python code. The suffixed versions were a workaround for bad performance in BaseRecord.get that should go away in DM-8716, and prior to that this change should let us run the code even if there's a temporary performance regression. As with the workarounds for DM-9112, though, it'd be good to put those changes on a separate commit so we can revert them easily later if we have to. Will that work?

Fine by me. I can make the replacements on Monday.

I think we already define these type-specific getters, just using a different name (e.g. _get_L or something like that). If so, I would expect it to be very simple to also generate identical wrappers using the public name (e.g. getL in the pybind11 wrapper. I would expect that to be trivial, and much simpler than changing all the python code, plus it would give the desired performance. Or is there some subtlety that I am missing?

No subtleties, so it sounds like Russell Owen's proposal is also viable; I just wanted to avoid too much effort on code that will go away. I'll leave it to Krzysztof Findeisen to decide which is easier.

Since it's not clear to me that the suffixed names should be part of the public BaseRecord interface, I would prefer to replace the names with get unless Russell has strong objections.

Due to performance I still lean towards leaving the code along and emulating the old API, but either solution is acceptable to me as long as all code is changed, not just the code that happens to be exposed by the unit tests we have run so far. In other words, I think a global search for each of the missing type-specific "get" method is required. It isn't difficult, just a minor nuisance.

Looks like cleaning this up is best left to DM-8716 after all. getD, at least, is used by some very high level packages like analysis and testingPipeQA. I'll wrap the Swig specializations for now.

Russell Owen I've updated afw, meas_base, ip_isr, and pipe_tasks. Can you take another look?

Excellent work. I had one small tweak to a comment (remove or reword) in pipe_tasks, but you can change it or not as you see fit.