[Numpy-discussion] Should we drop support for "one file" compilation mode?
Nathaniel Smith
njs at pobox.com
Tue Oct 6 12:58:20 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