Travis Oliphant wrote:
Carl Banks wrote:
Ok, I've thought quite a bit about this, and I have an idea that I
think will be ok with you, and I'll be able to drop my main
objection. It's not a big change, either. The key is to explicitly
say whether the flag allows or requires. But I made
Travis Oliphant wrote:
Carl Banks wrote:
My recommendation is, any flag should turn on some circle in the Venn
diagram (it could be a circle I didn't draw--shaped arrays, for
example--but it should be *some* circle).
I don't think your Venn diagram is broad enough and it un-necessarily
Travis Oliphant wrote:
Carl Banks wrote:
Travis Oliphant wrote:
Py_BUF_READONLY
The returned buffer must be readonly and the underlying object
should make
its memory readonly if that is possible.
I don't like the if possible thing. If it makes no guarantees, it
pretty much
Travis Oliphant wrote:
Py_BUF_READONLY
The returned buffer must be readonly and the underlying object
should make
its memory readonly if that is possible.
I don't like the if possible thing. If it makes no guarantees, it
pretty much useless over Py_BUF_SIMPLE.
Py_BUF_FORMAT
it as a real PEP. I believe this idea has run its course as
PEP XXX and needs a real number. (I was intending to start making
patches for the Py3K library modules as soon as that happened.)
Carl Banks
Travis Oliphant wrote:
Here is my final draft of the extended buffer interface PEP
Travis Oliphant wrote:
Carl Banks wrote:
Travis E. Oliphant wrote:
I think we are getting closer. What do you think about Greg's idea
of basically making the provider the bufferinfo structure and having
the exporter handle copying memory over for shape and strides if it
wants
Carl Banks wrote:
Here's a concrete example of where it would be useful: consider a
ByteBufferSlice object. Basically, the object represents a
shared-memory slice of a 1-D array of bytes (for example, Python 3000
bytes object, or an mmap object).
Now, if the ByteBufferSlice object
not be at the beginning of the new
buffer.
Other than that, looks good. :)
Carl Banks
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
(cc'ing back to Python-dev; the original reply was intended for it by I
had an email malfunction.)
Travis Oliphant wrote:
Carl Banks wrote:
3. Allow getbuffer to return an array of derefence offsets, one for
each dimension. For a given dimension i, if derefoff[i] is
nonnegative, it's
Travis Oliphant wrote:
Carl Banks wrote:
We're done. Return pointer.
Thank you for this detailed example. I will have to parse it in more
depth but I think I can see what you are suggesting.
First, I'm not sure why getbuffer needs to return a view object.
The view object in your
Travis Oliphant wrote:
Carl Banks wrote:
Tr
ITSM that we are using the word view very differently. Consider
this example:
A = zeros((100,100))
B = A.transpose()
You are thinking of NumPy's particular use case. I'm thinking of a
generic use case. So, yes I'm using the word view
11 matches
Mail list logo
