[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Serhiy Storchaka added the comment: Thank you Antoine! -- ___ Python tracker ___

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Change by Antoine Pitrou : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Antoine Pitrou added the comment: New changeset 0a2ff23fe6efb1653d655ac19d0a4e1629fd8d95 by Antoine Pitrou in branch 'master': Silence error output in test_concurrent_futures (bpo-21423) (#4347) https://github.com/python/cpython/commit/0a2ff23fe6efb1653d655ac19d0a4e1629fd8d95

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Change by Antoine Pitrou : -- pull_requests: +4304 stage: -> patch review ___ Python tracker ___

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Antoine Pitrou added the comment: Serhiy, I think I have found a way to deal with the logging output: https://github.com/python/cpython/pull/4347 -- stage: patch review -> ___ Python tracker

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Serhiy Storchaka added the comment: I'm not well experienced with logging, but if we can change the logging in subprocesses, I think we could change it to not output messages at all. It would be better to save logging messages in subprocesses and check that

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Vinay Sajip added the comment: > What is the best way to silence logging in subprocesses? Are you referring to the output shown in msg305601? If it's caused by logging statements, the best way would be either to pipe stderr to /dev/null or to change the logging to

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Serhiy Storchaka added the comment: What is the best way to silence logging in subprocesses? -- nosy: +vinay.sajip ___ Python tracker

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Antoine Pitrou added the comment: Unfortunately, there is no obvious way to capture the output of the child process here, short of running the entire test under a subprocess. -- ___ Python tracker

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Serhiy Storchaka added the comment: And please don't forget to edit a commit message when merge a PR. -- ___ Python tracker

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Serhiy Storchaka added the comment: test_concurrent_futures now produces too much output on stderr. $ ./python -m test test_concurrent_futures >/dev/null Exception in initializer: Traceback (most recent call last): File

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Change by Antoine Pitrou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Antoine Pitrou added the comment: New changeset 63ff4131af86e8a48cbedb9fbba95bd65ca90061 by Antoine Pitrou in branch 'master': bpo-21423: Add an initializer argument to {Process,Thread}PoolExecutor (#4241)

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Antoine Pitrou added the comment: By the way, the submitted PR follows Dan's argument about the initializer's argument: the actual call is `initializer(*initargs)`. If someone wants to know about the current thread or process, it's trivial to call `thread.current_thread()` or

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Antoine Pitrou added the comment: I've opened a PR for this at https://github.com/python/cpython/pull/4241, loosely based on Dan's last patch. -- ___ Python tracker

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Change by Antony Lee : -- nosy: -Antony.Lee ___ Python tracker ___ ___

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Change by Antoine Pitrou : -- pull_requests: +4206 ___ Python tracker ___ ___

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Change by Antoine Pitrou : -- versions: +Python 3.7 -Python 3.5 ___ Python tracker ___ ___

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Antony Lee added the comment: For cross-referencing purposes: I have proposed in http://bugs.python.org/issue25293 to allow passing a Thread/Process subclass as argument instead of an initializer function, which would both handle Mark Dickinson's comment

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Pedro Algarvio added the comment: Would also love to see this in the stdlib soon. My use case is logging setup(forward logs to the main process). -- ___ Python tracker

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Changes by Pedro Algarvio : -- nosy: +Pedro.Algarvio ___ Python tracker ___ ___

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Changes by John O'Connor : -- nosy: +jcon ___ Python tracker ___ ___ Python-bugs-list mailing

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Alexander Mohr added the comment: any chance if this getting into 3.5.2? I have some gross code to get around it (setting global properties) -- nosy: +thehesiod ___ Python tracker

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Changes by Shiming He heshim...@gmail.com: -- nosy: +Shiming He ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21423 ___ ___ Python-bugs-list

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Changes by Claudiu Popa pcmantic...@gmail.com: -- stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21423 ___ ___

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Changes by Claudiu Popa pcmantic...@gmail.com: -- nosy: +Claudiu.Popa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21423 ___ ___ Python-bugs-list

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Changes by Dan O'Reilly oreil...@gmail.com: -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21423 ___ ___ Python-bugs-list

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Mark Dickinson added the comment: I'm also not sure how useful it would be for ProcessPoolExecutor to receive an instance of itself. Agreed that this doesn't make much sense; I hadn't really thought about the ProcessPoolExecutor case. I withdraw my comments! --

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Changes by Nicholas Chammas nicholas.cham...@gmail.com: -- nosy: +Nicholas Chammas ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21423 ___ ___

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Changes by Dan O'Reilly oreil...@gmail.com: -- title: concurrent.futures.ThreadPoolExecutor should accept an initializer argument - concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument ___ Python tracker

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Dan O'Reilly added the comment: Here's an updated patch. Changes: * Fixed what appears to have been a find/replace typo I made prior to uploading the previous patch. * The tracebacks from the negative unit tests are now suppressed. * Fixed a race condition in the initializer failure

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Antoine Pitrou added the comment: It seems the addition of the initargs argument doesn't tackle Mark's objection here: the initialiser and uninitialiser for the EnhancedThreadPoolExecutor accept no arguments. In retrospect, it would have been better to have them take the thread itself as a

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Dan O'Reilly added the comment: It seems the addition of the initargs argument doesn't tackle Mark's objection here: the initialiser and uninitialiser for the EnhancedThreadPoolExecutor accept no arguments. In retrospect, it would have been better to have them take the thread itself

[issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument

Dan O'Reilly added the comment: Another updated patch. This one changes ProcessPoolExecutor behavior so that RuntimeErrors are raised in any active Futures, and on subsequent calls to submit after the initializer fails. This makes its behavior consistent with ThreadPoolExecutor. --