[Numpy-discussion] Should we drop support for "one file" compilation mode?

Nathaniel Smith njs at pobox.com
Tue Oct 6 13:09:41 EDT 2015


On Tue, Oct 6, 2015 at 9:51 AM, David Cournapeau <cournape at gmail.com> wrote:
>
> On Tue, Oct 6, 2015 at 5:44 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>
>> On Tue, Oct 6, 2015 at 4:46 AM, David Cournapeau <cournape at gmail.com>
>> wrote:
>> > The npy_ functions in npymath were designed to be exported. Those would
>> > stay
>> > that way.
>>
>> If we want to export these then I vote that we either:
>> - use the usual API export mechanism, or else
>> - provide a static library for people to link to, instead of trying to
>> do runtime binding. (I.e. drop it in some known place, and then
>> provide some functions for extension modules to find it at build time
>> -- similar to how np.get_include() works.)
>
> Unless something changed, that's more or less how it works already (npymath
> is used in scipy, for example, which was one of the rationale for writing it
> in the first place !).

Okay... in fact multiarray.so right now *does* export tons and tons of
random junk into the global symbol namespace (on systems like Linux
that do have a global symbol namespace), so it isn't obvious whether
people are asking for that to continue :-). I'm just specifically
saying that we should try to get this back down to the 1 exported
symbol.

(Try:
   objdump -T $(python -c 'import numpy; print(numpy.core.multiarray.__file__)')
This *should* print 1 line... I currently get ~700. numpy.core.umath
is similar.)

-n

-- 
Nathaniel J. Smith -- http://vorpus.org



More information about the NumPy-Discussion mailing list