Use context manager protocol for more multiprocessing types

[sbt]

BPO	15064
Nosy	@ned-deily

^{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:

assignee = None
closed_at = <Date 2012-06-19.13:20:14.226>
created_at = <Date 2012-06-14.12:13:45.261>
labels = ['type-feature']
title = 'Use context manager protocol for more multiprocessing types'
updated_at = <Date 2015-04-28.01:38:05.791>
user = 'https://bugs.python.org/sbt'

bugs.python.org fields:

activity = <Date 2015-04-28.01:38:05.791>
actor = 'ned.deily'
assignee = 'none'
closed = True
closed_date = <Date 2012-06-19.13:20:14.226>
closer = 'sbt'
components = []
creation = <Date 2012-06-14.12:13:45.261>
creator = 'sbt'
dependencies = []
files = []
hgrepos = []
issue_num = 15064
keywords = []
message_count = 5.0
messages = ['162776', '163107', '163119', '242120', '242162']
nosy_count = 5.0
nosy_names = ['ned.deily', 'tshepang', 'python-dev', 'sbt', 'dan.oreilly']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue15064'
versions = ['Python 3.3']

[sbt]

There are some types which should support the context manager protocol:

• connection objects
• listener objects
• pool objects

[python-dev]

New changeset 6d2a773d8e00 by Richard Oudkerk in branch 'default':
Issue bpo-15064: Implement context manager protocol for multiprocessing types
http://hg.python.org/cpython/rev/6d2a773d8e00

[python-dev]

New changeset 198382b4bcd0 by Richard Oudkerk in branch 'default':
Issue bpo-15064: Make BaseManager.__enter__() start server if necessary.
http://hg.python.org/cpython/rev/198382b4bcd0

New changeset 836d712461b3 by Richard Oudkerk in branch 'default':
Issue bpo-15064: Use with-blocks for some examples in docs.
http://hg.python.org/cpython/rev/836d712461b3

[danoreilly]

It's probably too late to do anything about this now, but wouldn't it make more sense for Pool.__exit__ to call close, rather than terminate? The vast majority of the time, that's probably what the user of the Pool would want to run. It also would make the behavior consistent with concurrent.futures.ProcessPoolExecutor, which will always wait for pending tasks to complete before exiting the with block.

[ned-deily]

Dan, this issue was closed and the code associated with it released a few years ago. Comments here will likely be ignored. If you want to pursue your suggestion, please open a new issue for it.