-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python 3.6 logging thread name regression with concurrent.future threads #73398
Comments
Logging statement using 'threadName' from concurrent.futures threads produce the wrong output with Python 3.6. The attached program with Python 3.5.X outputs: But with 3.6, it outputs: |
The bug seem to have been introduced by https://hg.python.org/cpython/rev/1002a1bdc5b1 |
Here is a patch that restores the previous behavior and update test to catch bogus naming. |
Thoughts anyone? This is a minor bug, but for a common use case (easy to hit), and the fix is trivial. |
Ping |
I don't think this is a regression, bug, bogos naming. I agree that "<concurrent.futures.thread.ThreadPoolExecutor object at 0x7f96711ac278>_0" is ugly. How about giving default thread_name_prefix less ugly? |
I don't think using repr(self) as a fallback was intentional, that is why I wrote regression, but I may be wrong. I agree that the previous default 'Thread-x' gives little information, but only the user can give a relevant name to describe what a thread is doing. Anyway as long as that repr string is replaced, I am happy :) |
OK. I'll wait for another opinions. |
Ping, so that this has a chance for the 3.6.1 release. |
Ping. I think any change, included Inada Naoki's idea above is better that the current behavior that pollutes the logging module output. Unfortunately I cannot rely on the 3.6 new thread_name_prefix argument for portability reasons, and have to manually patch my Python 3.6.x installs just to fix this. |
agreed the repr(self) name being surfaced is a regression even if technically "correct". your patch makes sense, but i think a nicer variant of it will be to name the thread ("Executor_" + str(num_threads)) when no thread_name_prefix is supplied. |
Thank you Gregory for the insight and new patch. Can this be merged in the 3.6 branch as well (targeting the 3.6.3 release)? |
Yes, I'll get this into 3.6. The default repr based name was clearly a regression from reasonable behavior. |
Gregory, please don't forget to backport the fix in the 3.6 branch, so that it is released with Python 3.6.3. Thank you |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: