Function purity / mutating inputs

[benfitzpatrick]

As per @cpelley's note, look at functions in IMPROVER and see how many both mutate their input and return output. It might be that we just want them to do one but not both. Function purity might be nice for most. Discuss with other core IMPROVER developers, then if agreed, do the work to change the functions (and/or redocument them), or propose follow on work.

[cpelley]

Thanks for raising @benfitzpatrick For functions where we identify a NEED to modify an object in-place (perhaps to save on memory by avoiding copies), we could adopt an approach like pandas by having an inplace=False keyword argument (making things explicit). In general, my feeling is that methods on objects are intuitively in-place operations, while module functions, given an object would not be (i.e. having an argument to make the later behaviour in-place as per suggestion above).