PR introduces Flake8 errors 😲

See test results for Failed build of commit aaea543c33

@LeonarddeR sorry for the collision, I did not notice you were already working on this when I filled PR #10269.

I do not think we need to fully revert the naming of gui.ExecuteAndPump, naming it in the initializer super call proves to do the trick.

As for your proposed change in watchdog.py, isn't CancellableCallThread.execute called by Thread.start? This would mean the thread is already correctly initialized, unless we cannot set the name once done… ?

The reason why I removed the logic that gets a name from the function is an unrelated issue. It's because functions defined in the python console have a module attribute of None. Trying to concatenate None with str results in an error.

The problem is here that we have to be absolutely sure about edge cases. Alternatively, we could use a try/except block to calculate a human readable name, but there's also something to say for consistency.

The reason why I removed the logic that gets a name from the function is an unrelated issue. It's because functions defined in the python console have a module attribute of None. Trying to concatenate None with str results in an error.

I also pushed a fix for this in PR #10269.

The problem is here that we have to be absolutely sure about edge cases. Alternatively, we could use a try/except block to calculate a human readable name, but there's also something to say for consistency.

A try/except block here would IMHO be overkill once we've nailed down the few different situations, but it of course couldn't hurt.
As for consistency, _FuncPtr are by nature different, and I do not feel much inconsistance in treating them differently, but this probably is just a matter of taste, no big deal.

EDIT: My second commit doesn't show up in PR #10269 as you closed it. Nevermind.

_FuncPtr isn't the only exception, functools.Partial also doesn't have a qualname

Good to know. Thanks for the precision.

I'm afraid I don't see the fix in #10269, probably because I closed it. Still, I think I want to be 100% sure that this works. Note that it is mainly for logging, it doesn't have to look super elegant.

I'm afraid I don't see the fix in #10269, probably because I closed it. Still, I think I want to be 100% sure that this works. Note that it is mainly for logging, it doesn't have to look super elegant.

No problem.
If you want to have a look, it's accessolutions/nvda@0167e5956d2 in branch accessolutions/nvda/i10266-threadLogFixup
I'm quite sure you have a much better view than I do about which functions get usually passed as the target of these two threads.
I can only notice that repr of a bound method is theoretically much more lengthy than this constructed fully qualified name, includes the id of the bound object and misses the module path.
Anyhow, PR #10259 already provides us with much more useful info than we got before it.
I'm already impacting my personal LogViewer quickNav tool to jump from/to entries of the same thread...