[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

Changes by Gregory P. Smith : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

Gregory P. Smith added the comment: New changeset 7d8282d25d4900dd3367daf28bb393be7f276729 by Gregory P. Smith in branch '3.6': [3.6] bpo-29212: Fix the ugly repr() ThreadPoolExecutor thread name. (GH-2315) (#3276)

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

Changes by Gregory P. Smith : -- pull_requests: +3319 ___ Python tracker ___ ___

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

desbma added the comment: 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 -- ___ Python tracker

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

Gregory P. Smith added the comment: Yes, I'll get this into 3.6. The default repr based name was clearly a regression from reasonable behavior. -- ___ Python tracker

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

Gregory P. Smith added the comment: New changeset a3d91b43c2851312fb942f31afa12f5961706db6 by Gregory P. Smith in branch 'master': bpo-29212: Fix the ugly repr() ThreadPoolExecutor thread name. (#2315) https://github.com/python/cpython/commit/a3d91b43c2851312fb942f31afa12f5961706db6

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

desbma added the comment: 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)? -- ___ Python tracker

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

Changes by Gregory P. Smith : -- pull_requests: +2365 ___ Python tracker ___ ___

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

Gregory P. Smith added the comment: 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.

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

desbma added the comment: 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

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

desbma added the comment: Ping, so that this has a chance for the 3.6.1 release. -- ___ Python tracker ___

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

INADA Naoki added the comment: OK. I'll wait for another opinions. -- ___ Python tracker ___ ___

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

desbma added the comment: 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.

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

Changes by Xiang Zhang : -- nosy: +gregory.p.smith ___ Python tracker ___ ___

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

INADA Naoki added the comment: I don't think this is a regression, bug, bogos naming. I agree that "_0" is ugly. But the name describes what is the thread, than "Thread-1". How about giving default thread_name_prefix less ugly? e.g. "ThreadPoolExecutor-worker". -- nosy: +inada.naoki

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

Changes by Ned Deily : -- nosy: +bquinlan ___ Python tracker ___ ___ Python-bugs-list

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

desbma added the comment: Ping -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

desbma added the comment: Thoughts anyone? This is a minor bug, but for a common use case (easy to hit), and the fix is trivial. -- ___ Python tracker

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

Changes by desbma : -- components: +Library (Lib) versions: +Python 3.7 ___ Python tracker ___

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

desbma added the comment: Here is a patch that restores the previous behavior and update test to catch bogus naming. -- keywords: +patch Added file: http://bugs.python.org/file46224/issue29212_1.patch ___ Python tracker

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

desbma added the comment: The bug seem to have been introduced by https://hg.python.org/cpython/rev/1002a1bdc5b1 -- ___ Python tracker ___

[issue29212] Python 3.6 logging thread name regression with concurrent.future threads

New submission from desbma: 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: MainThread From main thread Thread-1 From worker thread But with 3.6, it outputs: MainThread From main