I still don't understand why you cannot just include the header file as
is (without defining any of NO_IMPORT/PY_ARRAY_UNIQUE_SYMBOL).
I guess the real point is that no matter what definition (or lack
thereof) that I have for these macros, I still introduce header order
dependencies to users of
they'd likely crash.
Really?
I base that on the assumption that they'd not know to call
import_array() in that translation unit. This seems like a reasonable
assumption because, by defining the macros as such, they are strongly
implying that they expect the API functions to be imported for
On Thu, May 6, 2010 at 8:21 AM, Charles R Harris
charlesr.har...@gmail.comwrote:
On Thu, May 6, 2010 at 3:08 AM, Austin Bingham
austin.bing...@gmail.comwrote:
they'd likely crash.
Really?
I base that on the assumption that they'd not know to call
import_array() in that translation
On Thu, May 6, 2010 at 3:08 AM, Austin Bingham austin.bing...@gmail.comwrote:
they'd likely crash.
Really?
I base that on the assumption that they'd not know to call
import_array() in that translation unit. This seems like a reasonable
assumption because, by defining the macros as such,
On 05/04/2010 04:38 PM, Austin Bingham wrote:
I admit I'm having trouble formulating questions to address my
problems, so please bear with me.
Say I've got a shared library of utilities for working with numpy
arrays. It's intended to be used in multiple extension modules and in
some places
On Tue, May 4, 2010 at 7:05 AM, David Cournapeau courn...@gmail.com wrote:
On Mon, May 3, 2010 at 7:23 PM, Austin Bingham austin.bing...@gmail.com
wrote:
Hi everyone,
I've recently been developing a python module and C++ library in
parallel, with core functionality in python and C++ largely
On Mon, May 3, 2010 at 7:23 PM, Austin Bingham austin.bing...@gmail.com wrote:
Hi everyone,
I've recently been developing a python module and C++ library in
parallel, with core functionality in python and C++ largely just
layered on top of the python (with boost.python.) In some cases,
