The parking machine implementation
Not a finite state machine

The state machine in the posted code has infinite states.
This is caused by the recursive calls of get_coin and error.
Consider for example these states:


zero-pence with nothing entered yet
zero-pence, after zero-pence and an invalid input
zero-pence, after zero-pence and an invalid input twice
...


And so on. You can see these are different states,
because the content of the stack is different.

There are theoretically infinite zero-pence, five-pence, etc, states.
Practically there are finite, because after enough invalid inputs,
the stack will eventually overflow.

There should be precisely one zero-pence, five-pence, etc, states.

This is easy to fix by replacing the error function with a loop inside get_coin.

There are too many states

Even after making the states finite,
there will still be more states than required by the exercise.

Why, again, because of the stack.
For example, there are two ways to reach 10 pence:


0 -> 5 -> 5
0 -> 10


At this point, the machine should be in the 10 pence state,
but these two states are not the same,
because the stack stores two different histories.

If you want truly identical ten-pence, fifteen-pence, etc, states,
you have to eliminate history, you have to eliminate stack,
you have to eliminate function calls.

This is easy to fix by implementing state transitions in a loop,
instead of through function calls.

Don't use varargs if you don't need it

The get_coin function takes a variable number of functions as arguments.
But in fact it will only ever use 3,
and in fact it's only ever called with 3.
Therefore, it would be more natural to give those parameters dedicated, descriptive names.

Why convert input to int?

The get_coin function converts input to int,
but doesn't actually perform any numeric operations with it.

Use a more portable shebang

Not all systems have Python 3 installed in /usr/bin/python3.
A more robust, portable shebang would be:

#!/usr/bin/env python3