<p dir="ltr">On 10 Feb 2015 13:10, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> On Tue, 10 Feb 2015 11:26:22 -0800<br>
> Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
> > On 10 Feb 2015 09:11, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> > ><br>
> > ><br>
> > > Hello,<br>
> > ><br>
> > > I apologize for pinging the list, but I was wondering if there was<br>
> > > interest in either of <a href="https://github.com/numpy/numpy/pull/5457">https://github.com/numpy/numpy/pull/5457</a> (make<br>
> > > array data aligned by default) or<br>
> > > <a href="https://github.com/numpy/numpy/pull/5470">https://github.com/numpy/numpy/pull/5470</a> (make the array data allocator<br>
> > > configurable)?<br>
> ><br>
> > I'm not a fan of the configurable allocator. It adds new public APIs for us<br>
> > to support, and makes switching to using Python's own memory allocation<br>
> > APIs more complex. The feature is intrinsically dangerous, because newly<br>
> > installed deallocators must be able to handle memory allocated by the<br>
> > previous allocator. (AFAICT the included test case can crash the test<br>
> > process if you get unlucky and GC runs during it?).<br>
><br>
> It's taken care of in the patch.</p>
<p dir="ltr">Ah, I see -- I missed that you added an allocator field to PyArrayObject. That does reduce my objections to the patch. But I'm still not sure what problems this is solving exactly.</p>
<p dir="ltr">Also, if we do decide to add a deallocation callback to PyArrayObject then I think we should take advantage of the opportunity to also make life easier for c API users who need a custom callback on a case-by-case basis and currently have to jump through hoops using ->base.</p>
<p dir="ltr">-n</p>