storeInADS preserved in algorithm history and recreated correctly by script builder

[jhaigh0]

Description of work

Previously, scripts in the form

my_workspace = Algorithm(..., StoreInADS=False)
result = AnotherAlgorithm(InputWorkspace=my_workspace,...)

would be recreated via the ScriptBuilder as

Algorithm(OutputWorkspace='my_workspace',...)
AnotherAlgorithm(InputWorkspace='__TMP_<uid>',...)

which would not run as '__TMP_<uid>' is not a workspace in the ADS.

This PR aims to change this behaviour, so workspace histories can be recreated accurately.

Summary of work

• AlgorithmHistory now tracks whether StoreInADS was set to false.
• Workspaces will store their python variable name in the case they aren't stored in the ADS and given a name. This way it can be preserved between algorithm histories.
• ScriptBuilder will recreate assignment statements (ws = Algorithm(..)), add in StoreInADS=False when needed, and pass in workspace variables instead of strings.
• PropertyHistory will sotre if the property should be treated as python variable rather than a string.

Fixes #33252

To test:

I have been testing with this script.

dataX = [1,2,3,4,5,6,7,8,9,10] # or use dataX=range(1,11)
dataY = [1,2,3,4,5,6,7,8,9] # or use dataY=range(1,10)
ws = CreateWorkspace(dataX, dataY, StoreInADS=False)

# rebin from min to max - 1 with square root
result = Rebin(ws, "1, 3, 10", Power=0.5)

then right clicking result in the ADS -> Show History -> Copy to Clipboard and running the coppied script to check it works.

This could probably do with more complex testing though; I'm sure there will be edge cases where it doesn't quite work (reassigning python variable to a new name perhaps?) but my hope is not of these cases would have worked before either.

This is definitely a PR looking for feedback, if we should change the workspace history widget to reflect when workspaces aren't stored in the ADS for example.

---

Reviewer

Please comment on the points listed below (full description).
Your comments will be used as part of the gatekeeper process, so please comment clearly on what you have checked during your review. If changes are made to the PR during the review process then your final comment will be the most important for gatekeepers. In this comment you should make it clear why any earlier review is still valid, or confirm that all requested changes have been addressed.

Code Review

• Is the code of an acceptable quality?
• Does the code conform to the coding standards?
• Are the unit tests small and test the class in isolation?
• If there is GUI work does it follow the GUI standards?
• If there are changes in the release notes then do they describe the changes appropriately?
• Do the release notes conform to the release notes guide?

Functional Tests

• Do changes function as described? Add comments below that describe the tests performed?
• Do the changes handle unexpected situations, e.g. bad input?
• Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @mantidproject/gatekeepers will take care of it.

Gatekeeper

If you need to request changes to a PR then please add a comment and set the review status to "Request changes". This will stop the PR from showing up in the list for other gatekeepers.

[robertapplin]

I've tested this using StoreInADS=True and StoreInADS=False, and without StoreInADS. In all cases the generated python scripts execute as expected! I've also tried with StoreInADS=False and then assigning the output workspace to a new variable - it still seems to work well, so good job!

I just had a few picky suggestions, feel free to ignore!

[jhaigh0]

pre-commit.ci run

[robertapplin]

Thanks for the changes! This works well and the code additions look good, so happy to approve