-
Notifications
You must be signed in to change notification settings - Fork 18
Description
This is very similar to #61. I am partially of the mind of either implementing both or only implement set behavior and not dict behavior.
This came out of this discussion (copied below): https://hpcgitlab.hpc.inl.gov/experiment_analysis/mcnpy/-/issues/54#note_480927h.
To summarize: implement set-like arithmetic and binary logic. This will leads to complications with multiple problems though and #22, and #83 will be involved in the solution.
Labossiere-Hickman, Travis James
@tjlaboss
I do like the option of having a NumberedObjectCollection behave as a set. Since the collections can come from different models, though, the standard Python set logic might not be appropriate for identically-numbered but unequal objects. Three solutions:
Only allow set operations for NumberedObjectCollection instances linked to the same problem.
Allow them, but warn for every conflict.
Don't implement set operations, and just have the user manually do set(num_obj_col) if they want.
Gale, Micah David
@MicahGale
Just going to mention #61 here.
But this is very much an issue that I have been grappling for awhile, that lead to all those weird scripts that can't be upgraded that I showed you today @bascandr. This needs to ultimately get resolved by #22.
My overall view is that we should allow different problems. I think we need to be able to spot ostensibly identical objects to merge (for instance two files with common heritage). If they are the same they should merge. This then deals with problems of pointers though. Maybe we need to implement a hidden object state that just engages passthrough mode, probably knock that sort of thing out along with #83. But if there is a number collision of dissimilar objects I think the RHS (to be consistent) should be renumbered with a warning. Though this could cause issues if users didn't intend that. Maybe we need a system to rollback changes? Like a database? That would be actually really nice:
try:
problem.start_transaction()
... do error prone thing...
problem.commit()
except as e:
problem.roll_back()
raise eRealistically this would be a with statement most likely.
Suffice it to say I think we enough discussion to open a few new issues.