On Wed, Apr 16, 2014 at 12:51 PM, Julian Taylor <jtaylor.debian at googlemail.com> wrote: > Hi, > In NumPy what we want is the tracing, not the exchangeable allocators. > I don't think it is a good idea for the core of a whole stack of > C-extension based modules to replace the default allocator or allowing > other modules to replace the allocator NumPy uses. I don't think modules are ever supposed to replace the underlying allocator itself -- and it'd be very difficult to do this safely, since by the time any modules are imported there are already active allocations floating around. I think the allocator replacement functionality is designed to be used by applications embedding Python, who can set it up a special allocator before the interpreter starts. I'm not sure what exactly why one would need to swap out malloc and friends for something else, so I can't really judge, but it does at least seem plausible that if someone is taking the trouble to swap out the allocator like this then numpy should respect that and use the new allocator. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4