<br><br><div><span class="gmail_quote">On 1/5/07, <b class="gmail_sendername">Travis Oliphant</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Charles R Harris wrote:<br><br>><br>><br>> On 1/5/07, *Stefan van der Walt* <<a href="mailto:firstname.lastname@example.org">email@example.com</a><br>> <mailto:<a href="mailto:firstname.lastname@example.org">email@example.com</a>>> wrote:
<br>><br>> On Fri, Jan 05, 2007 at 09:38:49AM -0500, Neal Becker wrote:<br>> > Several extensions to Python utilize the buffer protocol to<br>> share<br>> > the location of a data-buffer that is really an N-dimensional
<br>> > array. However, there is no standard way to exchange the<br>> > additional N-dimensional array information so that the<br>> data-buffer<br>> > is interpreted correctly.
<br>> ><br>> > I am questioning if this is the best concept. It says that the<br>> data-buffer<br>> > will carry the information about it's interpretation as an<br>> N-dimensional
<br>> > array.<br>> ><br>> > I'm thinking that a buffer is just an interface to memory, and<br>> that the<br>> > interpretation as an array of n-dimensions, for example, is best
<br>> left to<br>> > the application. I might want to at one time view the data as<br>> > n-dimensional, but at another time as 1-dimensional, for example.<br>><br>> You can always choose to ignore that information if you don't need it.
<br>> On the other hand, if you *do* need it, how would you otherwise<br>> interpret an N-dimensional array, given only a buffer?<br>><br>><br>> I think Neal is suggesting some object that basically does nothing but
<br>> hold a pointer(s) to memory. This memory can be used in various ways,<br>> one of which is to use it construct another type of object that<br>> provides a view with indices and such, i.e., an array. That way the
<br>> memory isn't tied to arrays and could concievable be used in other<br>> ways. The idea is analagous to the data/model/view paradigm. It is a<br>> bit cleaner than just ignoring the array parts.<br><br>Such an object would be useful. I would submit that it is what the
<br>buffer object "should be"</blockquote><div><br>Yeah. The problem is that we have a buffer API, not a buffer object.<br></div><br>Chuck<br></div><br>