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 > The consumer will be using the format string information so make sure that > member is filled correctly. Is the idea to throw an exception if there's some other data format besides "b", and this flag isn't set? It seems superfluous otherwise. > Py_BUF_SHAPE > The consumer can (and might) make use of using the ndims and shape members > of the structure > so make sure they are filled in correctly. > > Py_BUF_STRIDES (implies SHAPE) > The consumer can (and might) make use of the strides member of the > structure (as well > as ndims and shape) Is there any reasonable benefit for allowing Py_BUF_SHAPE without Py_BUF_STRIDES? Would the array be C- or Fortran-like? 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. Carl _______________________________________________ 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-archive.com
