Various small MultiSignalBlocker cleanups #598
Conversation
src/pytestqt/wait_signal.py
Outdated
| self.signal_name = signal_name | ||
| self.args = args | ||
| signal_name: str | ||
| args: list[Any] |
There was a problem hiding this comment.
| args: list[Any] | |
| args: list[object] |
In this case, we don't care about the type of the object, for this reason object is safer: it will accept anything (just like Any), but contrary to Any, the type checker will flag if we accidentally try to perform some operation on it (say call a method).
There was a problem hiding this comment.
While we don't, this is exposed to users of the plugin, and we don't know what they want to do with those arguments. If we are going to make those types public in the future (and that's my goal), then users would have to cast those to do anything on it in that case, no?
There was a problem hiding this comment.
Ahh this is exposed? Then you are right, better to leave it as args: list[Any].
Not suggestion to this now, but I think a way to handle this correctly regarding types would would be to make this class Generic so users could type args according to their needs.
Btw should in this case args be tuple[Any, ...] then? Usually this is how *args is typed.
There was a problem hiding this comment.
Yep, see https://pytest-qt.readthedocs.io/en/latest/signals.html#getting-emitted-signals-and-arguments:
To determine which of the expected signals were emitted during a
wait()you can useblocker.all_signals_and_argswhich contains a list ofwait_signal.SignalAndArgsobjects, indicating the signals (and their arguments) in the order they were received.
I don't think this can be made generic, as the arguments will depend on the signal being recorded, and we don't know which signals (and how many in total) there will be in there.
Good catch regarding tuple[Any, ...], will adjust accordingly.
A couple of things I noticed while working on #594 (which I'll probably abandon as it seems to bring more trouble than it fixes).