Explicit buffer release for memoryview objects

[ncoghlan]

BPO	9789
Nosy	@gvanrossum, @ncoghlan, @pitrou
Superseder	bpo-9757: Add context manager protocol to memoryviews

^{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 2010-09-07.13:37:10.968>
created_at = <Date 2010-09-07.12:53:13.491>
labels = ['type-feature']
title = 'Explicit buffer release for memoryview objects'
updated_at = <Date 2010-09-07.13:37:30.180>
user = 'https://github.com/ncoghlan'

bugs.python.org fields:

activity = <Date 2010-09-07.13:37:30.180>
actor = 'ncoghlan'
assignee = 'none'
closed = True
closed_date = <Date 2010-09-07.13:37:10.968>
closer = 'ncoghlan'
components = []
creation = <Date 2010-09-07.12:53:13.491>
creator = 'ncoghlan'
dependencies = []
files = []
hgrepos = []
issue_num = 9789
keywords = []
message_count = 4.0
messages = ['115753', '115754', '115755', '115757']
nosy_count = 3.0
nosy_names = ['gvanrossum', 'ncoghlan', 'pitrou']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = '9757'
type = 'enhancement'
url = 'https://bugs.python.org/issue9789'
versions = ['Python 3.2']

[ncoghlan]

memoryview objects currently offer no way to explicitly release the underlying buffer.

This may cause problems for mutable objects that are locked while PEP-3118 buffer references remain unreleased (e.g. in 3.2, io.BytesIO supports getbuffer() for direct access to the underlying memory, but disallows resizing until the associated memoryview goes away).

This isn't too bad in CPython due to explicit refcounting, but may be an issue when using other implementations since the time between release of the last reference and actual garbage collection is indeterminate. For example, the new test_getbuffer in the BytesIOMixin class in the test suite relies on "del buf" promptly releasing the underlying PEP-3118 buffer, which may not be the case on other implementations.

So there are two separate questions here:

1. Whether or not to add an explicit "release()" method to memoryview objects (this would be sufficient to address the problem)
2. Whether or not to add direct context management support to memoryview objects (this isn't really necessary, since a short context manager can do the same thing, but may be a nice convenience)

Nosy list members added based on relevant python-dev discussion where GvR previously nixed part 2 of the idea. At the time, I hadn't really separated the two questions properly in my mind, but I suspect the failing to do something about the first one will prove problematic in the long run (or even the short run, as the test suite issue suggests).

[ncoghlan]

The test suite actually does force a GC collection cycle, so the test may be more portable than I first thought, but the need to do that suggests an explicit buffer release API may be a more appropriate solution.

[pitrou]

See the context management patch at bpo-9757.

[ncoghlan]

Thanks for that link. Compared to what either of us managed in the original thread, I think my first post here better articulates why the ability to explicitly release the buffer is important - not because of general memory usage, but because the object owning the buffer (e.g. a BytesIO instance) may behave differently while the buffer reference exists.

It wasn't until I saw the actual getbuffer() patch on python-checkins that this rationale actually clicked for me.