LumensalisCP.util.kwCallback
Module Contents
Classes
KWCallback | wrapper for a callable, allowing it be invoked safely(ish) with more positional and/or named parameters than expect. Extra parameters will be silently discarded instead of raising an exception. |
|---|
API
class LumensalisCP.util.kwCallback.KWCallback(cb: LumensalisCP.CPTyping.Callable, name: str | None = None, requiredKwds: LumensalisCP.CPTyping.List[str] | None = None)
Bases: object
wrapper for a callable, allowing it be invoked safely(ish) with more positional and/or named parameters than expect. Extra parameters will be silently discarded instead of raising an exception.
This is not terribly efficient. It has a small risk of unexpected side effects. It is (IMHO) a rather inelegant hack. It provides a workaround for a limitation in CircuitPython / MicroPython - there is no way to determine what arguments are recognized (normally you could use inspect.signature(…) ).
Each instance tracks the maximum allowed number of unnamed arguments, as well as the names of unrecognized named arguments. When invoking the callback, positional arguments beyond the maximum allowed and known unrecognized names are removed before invoking the wrapped callback.
When an invocation triggers an “unexpected argument” exception, the position (for unnamed args) or name (for named args) is stored and the callback is re-invoked until it succeeds or throws an exception other than those used for unexpected arguments.
WARNING: if the state of anything changes - including the state of any arguments between the nested invocation and the catching of the argument exception prior to updating this instance’s max allowed / name blacklist and re-invocation, it could cause some rather strange and unexpected behavior. This is probably not likely to occur without some twisted code (like explicitly throwing a TypeError with a very similar message), but…