[Numpy-discussion] Fixing numpy 1.4.0 ABI breakage, and a plea for self-contained, small commits
Dag Sverre Seljebotn
Wed Jan 27 02:48:37 CST 2010
Charles R Harris wrote:
> On Tue, Jan 26, 2010 at 10:02 PM, David Cournapeau
> <firstname.lastname@example.org <mailto:email@example.com>> wrote:
> Charles R Harris wrote:
> > Whatever we do, it would be good to figure out some way to avoid
> > problem in the future. We could hide access to the array, for
> > But again, that would require a lot of other code mods. Hmm...
> That's something that we have to do at some point if we care about ABI
> (I think we should care - expecting people to recompile all the
> extensions for a new version of numpy is a big hindrance).
> Assuming python 1.5 will have py3k support, I was wondering about
> starting working on NumPy 2.0, with massive changes to the C API
> so that
> we can avoid this problem in the future: no more "naked" structures,
> much cleaner/leaner headers to avoid accidental reliance on specific
> private binary layouts, etc...
> 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.
> 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.
Huh? The PEP 3118 buffer format strings "Zf", "Zd", "Zg" are
respectively complex float, double, long double.
Any other reasons PEP 3118 can't be used? Not saying I believe there
isn't, I'm just curious...
More information about the NumPy-Discussion