This is about idempotent operations, which are basically state changes that have the same affect if executed multiple times as if executed once:

  $ chmod a+x file
  $ chmod a+x file

This is linked to mathematical idempotence in the sense that an operation is a function which takes some inputs i and the state of the world S and produces a new state S':

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.

Posting this to drive people crazy :) (only kidding)

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).

For HTTP resources, this is addressed in RFC7231 - essentially, servers may implement non-idempotent behavior such as logging for methods otherwise considered idempotent.

https://tools.ietf.org/html/rfc7231#section-4.2.2

A more idempotency-friendly API would be:

    setAccountLockStatus('user', LockStatus.LOCKED)

Or maybe ensureAccountLocked('user')?

Your error changed the state S of the world.

You're right, and the technical distinction is warranted, but the definition you give is still not equivalent to that of being mathematically idempotent, since the domain and range of f are not isomorphic.

That's only because the domain is multi-dimensional, while the range is the domain of just the first argument.

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).

One of my favorite parts of Python is the idempotent type casting functions.

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.

In category theory we also say h is idempotent iff h^2 = h whereas h is an endomorphism.

The "morphism" property is completely unneeded for idempotence and the "endo" part is implied :)

This differs from the definition in the article. I think the article's definition is the significantly more common one for software engineering.