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
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 allows or
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 much that
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. Otherwise
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 you
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 and
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
changes as
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
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:
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
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).
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. If no copy was
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 appears
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 decision
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 be part
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;
int
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
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
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;
} PyMemoryViewObject;
If
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
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
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:
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
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
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 over
25 matches
Mail list logo
