-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
Python 3.6 logging thread name regression with concurrent.future threads #73398
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: