[Numpy-discussion] Fixing numpy 1.4.0 ABI breakage, and a plea for self-contained, small commits

Charles R Harris charlesr.harris at gmail.com
Wed Jan 27 11:04:32 EST 2010

On Wed, Jan 27, 2010 at 1:48 AM, Dag Sverre Seljebotn <
dagss at student.matnat.uio.no> wrote:

> Charles R Harris wrote:
> >
> >
> > On Tue, Jan 26, 2010 at 10:02 PM, David Cournapeau
> > <david at silveregg.co.jp <mailto:david at silveregg.co.jp>> wrote:
> >
> >     Charles R Harris wrote:
> >
> >     >
> >     > Whatever we do, it would be good to figure out some way to avoid
> >     this
> >     > problem in the future. We could hide access to the array, for
> >     instance.
> >     > 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
> >     (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...
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
const char *formatA *NULL* terminated string in
style syntax giving the contents of the elements available through
the buffer. If this is *NULL*, "B" (unsigned bytes) is assumed.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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20100127/1571539d/attachment.html>

More information about the NumPy-Discussion mailing list