Travis Oliphant wrote:
> you would like to make the original memory
> read-only until you are done with the algorithm and have copied the data
> back into memory.
Okay, I see what you mean now.
Maybe this should be called Py_BUF_LOCK_CONTENTS or
something to make the semantics clearer. Otherwis
"Travis Oliphant" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| I'm good with using an identifier to differentiate between an "allowed"
| flag and a "require" flag. I'm not a big fan of
| VERY_LONG_IDENTIFIER_NAMES though. Just enough to understand what it
| means but not so mu
Carl Banks wrote:
> 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
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
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 a few other
> change
Jim Jewett wrote:
> Reading this message without the entire PEP in front of me showed some
> confusing usage. (Details below) Most (but not all) I could resolve
> from the PEP itself, but they could be clarified with different
> constant names.
>
I'm going to adapt some suggestions made by you
Greg Ewing wrote:
> Carl Banks wrote:
>
>> Py_BUF_REQUIRE_READONLY - Raise excpetion if the buffer is writable.
>
> Is there a use case for this?
Yes. The idea is used in NumPy all the time.
Suppose you want to write to an array but only have an algorithm that
works with contiguous data. Then
Carl Banks wrote:
> Py_BUF_REQUIRE_READONLY - Raise excpetion if the buffer is writable.
Is there a use case for this?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
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
Reading this message without the entire PEP in front of me showed some
confusing usage. (Details below) Most (but not all) I could resolve
from the PEP itself, but they could be clarified with different
constant names.
Counter Proposal at bottom, and specific questions in between.
Travis Olipha
Greg Ewing wrote:
> Travis Oliphant wrote:
>
>> It is more convenient to store any slicing information (so a memory
>> view object could store an arbitrary slice of another object) as
>> offsets, lengths, and skips which can be used to adjust the memory
>> buffer returned by base.
>
> What happe
Travis Oliphant wrote:
> Py_BUF_SIMPLE --- you are requesting the simplest possible (0x00)
>
> Py_BUF_WRITEABLE -- get a writeable buffer (0x01)
>
> Py_BUF_READONLY -- get a read-only buffer(0x02)
I don't see how these three form a progression.
From the other things you say, it appe
Travis Oliphant wrote:
> It is more convenient to store any slicing information (so a memory view
> object could store an arbitrary slice of another object) as offsets,
> lengths, and skips which can be used to adjust the memory buffer
> returned by base.
What happens if the base object change
On 4/13/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> >> int PyObject_GetContiguous(PyObject *obj, void **buf, Py_ssize_t
> >> *len,
> >>int fortran)
> >>
> >> Return a contiguous chunk of memory representing the buffer. If a
> >> copy is made then return 1.
Carl Banks wrote:
>
> The thing that bothers me about this whole flags setup is that
> different flags can do opposite things.
>
> Some of the flags RESTRICT the kind of buffers that can be
> exported (Py_BUF_WRITABLE); other flags EXPAND the kind of buffers that
> can be exported (Py_BUF_INDIRECT
Lisandro Dalcin wrote:
> On 4/9/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
>
> Travis, all this is far better and simpler than previous approaches...
> Just a few comments
Thanks for your wonderful suggestions. I've incorporated many of them.
>
> 1) I assume that 'bufferinfo' structure will b
Neil Hodgson wrote:
> Travis Oliphant:
>
>> PEP: 3118
>> ...
>
> I'd like to see the PEP include discussion of what to do when an
> incompatible request is received while locked. Should there be a
> standard "Can't do that: my buffer has been got" exception?
I'm not sure what standard to make a d
Travis Oliphant wrote:
> Because slicing NumPy array's already does it by holding on to a view, I
> guess having an object that doesn't hold on to a view in Python but
> "re-gets" it every time it is needed, would be useful.
I guess this problem doesn't arise in NumPy, because the size
of the m
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 guarant
Greg Ewing wrote:
> From PEP 3118:
>
> A memory-view object is an extended buffer object that
> should replace the buffer object in Python 3K.
>
> typedef struct {
> PyObject_HEAD
> PyObject *base;
> struct bufferinfo view;
> int itemsize;
> int flags;
> } PyMemoryViewOb
From PEP 3118:
A memory-view object is an extended buffer object that
should replace the buffer object in Python 3K.
typedef struct {
PyObject_HEAD
PyObject *base;
struct bufferinfo view;
int itemsize;
int flags;
} PyMemoryViewObject;
If the purpose is to pr
Lisandro Dalcin wrote:
> 4) I am not sure about this, but perhaps 'buferingo' should save the
> flags passed to 'getbuffer' in a 'flags' field. This can be possibly
> needed at 'releasebuffer' call.
The object isn't necessarily providing all the things
that were requested in the flags, so it's go
On 4/9/07, Travis Oliphant <[EMAIL PROTECTED]> wrote:
Travis, all this is far better and simpler than previous approaches...
Just a few comments
> The bufferinfo structure is::
>
> struct bufferinfo {
>void *buf;
>Py_ssize_t len;
>int readonly;
>char *format;
>
Carl Banks wrote:
> Another little mistake I made: looking at the Python source, it seems
> that most C defines do not use the Py_ prefix, so probably we shouldn't
> here. Sorry.
Most of the #define's aren't exposed via Python.h and aren't part of the
public C API. The public ones are meant to
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 useless ove
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_FORM
Travis Oliphant:
> PEP: 3118
> ...
I'd like to see the PEP include discussion of what to do when an
incompatible request is received while locked. Should there be a
standard "Can't do that: my buffer has been got" exception?
Neil
___
Python-Dev m
Changes:
* added the "flags" variable to allow simpler calling for getbuffer.
* added some explanation of ideas that were discussed and abandoned.
* added examples for simple use cases.
* added more C-API calls to allow easier usage.
Thanks for all feedback.
-Travis
PEP: 3118
Title:
28 matches
Mail list logo
