<br><br><div class="gmail_quote">On Tue, Jan 26, 2010 at 10:02 PM, David Cournapeau <span dir="ltr"><<a href="mailto:david@silveregg.co.jp">david@silveregg.co.jp</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>
> Whatever we do, it would be good to figure out some way to avoid this<br>
> problem in the future. We could hide access to the array, for instance.<br>
> But again, that would require a lot of other code mods. Hmm...<br>
<br>
</div>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 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>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br>NumPy 2.0 is going to be a *lot* of work. And I've been thinking about it lately, mostly because I was looking over the same code where you found this problem. What I didn't know was how public the code was. Good find, BTW.<br>
<br>One thought was to start by separating out the ufuncs and their dependency on ndarrays. But then I looked at the new buffer interface and it just won't do as a replacement, no complex numbers, etc. Maybe it can be extended. Anyway, if we make a move it needs to be well planned.<br>
<br>Chuck <br></div></div>