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.

Author pitrou
Recipients kermode, loewis, mark.dickinson, ncoghlan, pitrou, rupole, teoliphant
Date 2011-01-05.16:52:46
SpamBayes Score 2.220571e-10
Marked as misclassified No
Message-id <1294246363.3701.11.camel@localhost.localdomain>
In-reply-to <1294245057.59.0.77479060851.issue10181@psf.upfronthosting.co.za>
Content
> However, I believe the current memoryview implementation does the
> wrong thing and only calls them once, and then duplicates the
> Py_buffer structures without ever going back to the original objects
> (that opinion was based on a quick scan of the code a while back, but
> it would fit with the uncomplimentary sentiments Antoine has expressed
> in trying to get all this to exhibit some kind of consistency)

Actually, and unless I made a mistake, it does call them twice.
(and does the slicing by hand afterwards, which explains part of the
hilarity with smalltable and friends :-))

> For point 2, it must be the same pointer. When the PEP says "the
> same", I agree it could be taken as ambiguous, but the later reference
> to the exporter managing a linked-list of exported views makes it
> clear that identity is what matters.

The common idiom (including in code not written by me :-)) is currently
to use Py_buffer variables allocated on the C stack.

Also, we have the C API function PyMemoryView_FromBuffer() which
basically mandates that Py_buffer structs can be copied around. And it's
a very useful function since it allows to create a memoryview from a
chunk of anonymous memory.
History
Date User Action Args
2011-01-05 16:52:49pitrousetrecipients: + pitrou, loewis, teoliphant, mark.dickinson, ncoghlan, rupole, kermode
2011-01-05 16:52:46pitroulinkissue10181 messages
2011-01-05 16:52:46pitroucreate