A function f is idempotent if: f(f(x)) = f(x)
The "absolute value" function is idempotent: abs(abs(-42)) = abs(-42)
The "squared" function is not: sq(sq(7)) != sq(7)
The "absolute value" function is idempotent: abs(abs(-42)) = abs(-42)
The "squared" function is not: sq(sq(7)) != sq(7)
$ chmod a+x file
$ chmod a+x file
S' = f(S, i).
So then if f(f(S, i), i) = f(S, i) then f is idemponent mathematically, and the operation is idempotent in the software sense.
We can fold the input into S. That is to say, the input is just an aspect of the state of the word, and then we can reduce f(S, i) to just f(S), so then we have f(f(S)) = f(S).
How about state changes as a side effect, with a near meaningless result.
LockAccount('user')
The account is now locked.
LockAccount('user')
Error: The account was already locked!
However, the internal state of the user after the second operation remains the same. We also cannot use any of the information in the result as something meaningful as shown in these math equations because the API has a wall over an opaque data structure. Which is often not the case in Math. Similar to chmod, there might be a low-level file API that throws an internal error because the file is already executable, but the chmod wrapper hides that possible error. (It probably doesn't have an error internally, but for argument sake).
setAccountLockStatus('user', LockStatus.LOCKED)Say you have a function that takes a list as input, but sometimes a tuple is passed. Wrapping the input like lvalues = list(values), ensures that lvalues will always be a list (or it throws a type error), so you won't get annoying attribute errors, when trying to access the list's methods. In the case of a list type(list([])).__name__ == 'list', as does type(list(list([]))).__name__, etc.
This can get a bit tricky with situations where type casting may be undesirable, say casting a string to a list. So judicious use is necessary.