[Numpy-discussion] PyBUF_SIMPLE/PyBUF_FORMAT: casts to unsigned bytes

[Stefan Krah]

Dag Sverre Seljebotn <d.s.seljebotn at astro.uio.no> wrote:
> Under 2), would it make sense to also export the contents of a
> Fortran-contiguous buffer as a raw byte stream? I was just the other week
> writing code to serialize an array in Fortran order to a binary stream.

Probably, since it works now and people might have gotten used to it.


It breaks the current hierarchy of requests though:

PyBUF_INDIRECT -> suboffsets + strides (PIL-style)
PyBUF_STRIDES -> strides (NumPy-style)
PyBUF_ND -> C-contiguous
PyBUF_SIMPLE -> cast from C or Fortran contiguous to unsigned bytes

The last one would be a step up in complexity again. If Fortran
contiguous weren't allowed, one could assume that all buffers below
(and including) PyBUF_ND are C-contiguous.


It is still not clear to me what value itemsize should have if
if PyBUF_FORMAT is not given. As I see it, the rules are [1]:

Request without PyBUF_FORMAT -> view.format must be NULL -> 'B'.

Then itemsize = 'number of bytes implied by the format' = 1.


This would work for viewing contiguous buffers as byte streams,
but what about non-contiguous buffers?

   PyBUF_STRIDED: (PyBUF_STRIDES | PyBUF_WRITABLE)

How should the buffer be used if itemsize is set to 1? For example,
it seems impossible to implement tobytes() if the real itemsize is
missing.


Travis, if you have time, it would be very nice to have your input
on this one, too.


Stefan Krah


[1] format:

    "a NULL-terminated format-string (following the struct-style syntax
    including extensions) indicating what is in each element of memory.
    The number of elements is len / itemsize, where itemsize is the number
    of bytes implied by the format. This can be NULL which implies standard
    unsigned bytes ("B")."