real-or-random
commented
1 month ago Okay, I reworked the entire thing and the API is totally different now from the first version. Instead of adding blame: bool and similar parameters in the necessary locations, this now adds separate _blame functions. In particular, there are _participant_blame functions, which can be used after participant_step2 has failed. Fortunately, this works without the need to redo expensive computations in participant_blame (or carry over cached values from participant_step2 to participant_blame via the raised exception, which would be rather inelegant). I think this is much better:
- The code is simpler and easier to read.
- No more boolean flags and
Optional, which are difficult in static typing. - People can easily ignore the blame stuff by just not looking at the
_blamefunctions.
Still to do:
- [ ] Add docstrings for the new functions and change docs for the modified exceptions:
- [x] Add blaming to the example, i.e., add the code to catch the error in step2 and perform the blame phase so that we have a full interactive ("async") application example with blame. (The example currently runs fine without blame, but this is just because everyone is honest.)
- [ ] (The other items in #37.)
Please let me know if this API looks good, then we merge this and I can work on follow-up PRs.
Solves partly #37, namely the actual implementation of the idea.
Draft because there are some minor cleanups left, see added FIXMEs.