This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2010年11月02日 09:26 by kristjan.jonsson, last changed 2022年04月11日 14:57 by admin. This issue is now closed.
| Messages (5) | |||
|---|---|---|---|
| msg120211 - (view) | Author: Kristján Valur Jónsson (kristjan.jonsson) * (Python committer) | Date: 2010年11月02日 09:26 | |
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. |
|||
| msg120435 - (view) | Author: Antoine Pitrou (pitrou) * (Python committer) | Date: 2010年11月04日 20:24 | |
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.
|
|||
| msg120436 - (view) | Author: Antoine Pitrou (pitrou) * (Python committer) | Date: 2010年11月04日 20:30 | |
Done in r86174. |
|||
| msg120467 - (view) | Author: Kristján Valur Jónsson (kristjan.jonsson) * (Python committer) | Date: 2010年11月05日 02:52 | |
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.... |
|||
| msg142421 - (view) | Author: Stefan Krah (skrah) * (Python committer) | Date: 2011年08月19日 10:00 | |
I think PyBUF_SHADOW was the renamed version of PyBUF_UPDATEIFCOPY from the PEP. :) |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:08 | admin | set | github: 54502 |
| 2011年08月19日 10:00:14 | skrah | set | nosy:
+ skrah messages: + msg142421 |
| 2010年11月05日 02:52:23 | kristjan.jonsson | set | messages: + msg120467 |
| 2010年11月04日 20:30:49 | pitrou | set | status: open -> closed resolution: fixed messages: + msg120436 |
| 2010年11月04日 20:24:19 | pitrou | set | messages: + msg120435 |
| 2010年11月04日 08:36:34 | georg.brandl | set | assignee: pitrou nosy: + pitrou |
| 2010年11月02日 09:26:32 | kristjan.jonsson | create | |