[issue10293] PyMemoryView object has obsolete members

[Stefan Krah]

Stefan Krah  added the comment:

I think PyBUF_SHADOW was the renamed version of PyBUF_UPDATEIFCOPY
from the PEP. :)

--
nosy: +skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10293] PyMemoryView object has obsolete members

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Ah, the SHADOW member...
Weird.
Anyway, I have been hacking around in the memory view.  One thing that it does, 
and makes me uncomfortable since I think it is breaking the new buffer 
protocol, is to 
a) PyObject_GetBuffer()
b) Modify the resulting local Py_buffer
c) releaseing that modified Py_buffer when it calls PyBuffer_Release()

I don't think one can do that, strictly speaking.  You don't know what the 
buffer_releasebuffer() slot actually does, it might use the Py_buffer's "buf" 
member to release internal data, so I don't think it is permissable to mess 
with it.

I was hacking away at the MemoryView to make it behave differently, perhaps 
more like the SHADOW buffer concept:  When you call buffer_getbuffer on a 
memoryview, it returns a new Py_buffer that reflects its own view of the 
underlying object.  In other words, it doesn't call PyObject_GetBuffer again on 
the underlying object  A memoryview object should, IMHO, only perform that call 
once on the underlying object, and then serve its own view to its clients.

Slicing memoryview objects should also be done differently.  Rather than 
calling PyObject_GetBuffer() on the underlying object, it should rather refer 
to the origina MemoryView object, and create a local modification of that view.

The only problem with this approact that I have found (having run the 
testsuite) is that the buffer_getbuffer slot now has to do more work, since it 
cannot simply call PyObject_GetBuffer() on some underlying object.  It must now 
interpret flags and other things

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10293] PyMemoryView object has obsolete members

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Done in r86174.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10293] PyMemoryView object has obsolete members

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, there's this strange-looking thing in PyMemoryView_GetContiguous:

if (buffertype == PyBUF_SHADOW) {
/* return a shadowed memory-view object */
view->buf = dest;
mem->base = PyTuple_Pack(2, obj, bytes);

... but I don't really want to bother. Let's remove it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10293] PyMemoryView object has obsolete members

[Georg Brandl]

Changes by Georg Brandl :


--
assignee:  -> pitrou
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10293] PyMemoryView object has obsolete members

[Kristján Valur Jónsson]

New submission from Kristján Valur Jónsson :

The PyMemoryObject has a "base" member which appears to be obsolete.  
Furthermore, the function do_release() attempt to perform some obsolete-looking 
woodo with base if it happens to be a tuple.  Looks dangerous.

--
components: Interpreter Core
messages: 120211
nosy: krisvale
priority: normal
severity: normal
status: open
title: PyMemoryView object has obsolete members
type: behavior
versions: Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com