<br><br><div class="gmail_quote">On Wed, Jan 27, 2010 at 1:48 AM, Dag Sverre Seljebotn <span dir="ltr"><<a href="mailto:dagss@student.matnat.uio.no">dagss@student.matnat.uio.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Charles R Harris wrote:<br>
><br>
><br>
> On Tue, Jan 26, 2010 at 10:02 PM, David Cournapeau<br>
</div><div><div></div><div class="h5">> <<a href="mailto:david@silveregg.co.jp">david@silveregg.co.jp</a> <mailto:<a href="mailto:david@silveregg.co.jp">david@silveregg.co.jp</a>>> wrote:<br>
><br>
>     Charles R Harris wrote:<br>
><br>
>     ><br>
>     > Whatever we do, it would be good to figure out some way to avoid<br>
>     this<br>
>     > problem in the future. We could hide access to the array, for<br>
>     instance.<br>
>     > But again, that would require a lot of other code mods. Hmm...<br>
><br>
>     That's something that we have to do at some point if we care about ABI<br>
>     (I think we should care - expecting people to recompile all the<br>
>     extensions for a new version of numpy is a big hindrance).<br>
><br>
>     Assuming python 1.5 will have py3k support, I was wondering about<br>
>     starting working on NumPy 2.0, with massive changes to the C API<br>
>     so that<br>
>     we can avoid this problem in the future: no more "naked" structures,<br>
>     much cleaner/leaner headers to avoid accidental reliance on specific<br>
>     private binary layouts, etc...<br>
><br>
><br>
> NumPy 2.0 is going to be a *lot* of work. And I've been thinking about<br>
> it lately, mostly because I was looking over the same code where you<br>
> found this problem. What I didn't know was how public the code was.<br>
> Good find, BTW.<br>
><br>
> One thought was to start by separating out the ufuncs and their<br>
> dependency on ndarrays. But then I looked at the new buffer interface<br>
> and it just won't do as a replacement, no complex numbers, etc. Maybe<br>
> it can be extended. Anyway, if we make a move it needs to be well planned.<br>
</div></div>Huh? The PEP 3118 buffer format strings "Zf", "Zd", "Zg" are<br>
respectively complex float, double, long double.<br>
<br>
Any other reasons PEP 3118 can't be used? Not saying I believe there<br>
isn't, I'm just curious...<br>
<font color="#888888"><br></font></blockquote><div><br>I wasn't looking at the PEP, I was looking at the python 3.x documentation which claims that the type strings used the same notation as the struct module.<br><dl class="cmember">
<dt>const char *<tt class="descname">format</tt></dt><dd>A <em>NULL</em> terminated string in <a title="Interpret strings as packed binary data." class="reference external" href="http://docs.python.org/library/struct.html#module-struct"><tt class="xref docutils literal"><span class="pre">struct</span></tt></a> module style syntax giving
the contents of the elements available through the buffer.  If this is
<em>NULL</em>, <tt class="docutils literal"><span class="pre">"B"</span></tt> (unsigned bytes) is assumed.</dd></dl>I assumed that the PEP would be more compatible since Travis put it together and that it was changed on the journey to python inclusion. It could also be the case that the python documentation isn't correct ;) But if we go over to a buffer interface we need to use what was in the PEP.<br>
<br>Chuck<br><br></div></div>