[Numpy-discussion] ANN: Numpy 1.6.1 release candidate 1
Tue Jun 21 15:52:21 CDT 2011
On Tue, Jun 21, 2011 at 10:05 PM, Ralf Gommers
> On Tue, Jun 21, 2011 at 4:38 PM, Bruce Southey <email@example.com> wrote:
>> On 06/21/2011 01:01 AM, Ralf Gommers wrote:
>> On Tue, Jun 21, 2011 at 3:55 AM, Bruce Southey <firstname.lastname@example.org>wrote:
>>> So what is the actual name of the multiarray shared library with the Mac?
>>> If it is ' 'multiarray.so' then the correct name is "libname +
>>> sysconfig.get_config_var('SO')" as I previously indicated.
>>> It is, and yes that's correct. Orthogonal to the actual issue though.
>> While the test now pass, you have now changed an API for load_library.
> Only in a backwards-compatible way, which should be fine. I added a
> keyword, the default of which does the same as before. The only thing I did
> other than that was remove tries with clearly invalid extensions, like
> ".pyd" on Linux. Now that I'm writing that though, I think it's better to
> try both ".so" and ".cpython-32mu.so" by default for python >=3.2.
This should try both extensions:
Does that look better?
>> This is not something that is meant to occur in a bug-fix release as well
>> as the new argument is undocumented. But I do not understand the need for
>> this extra complexity when "libname + sysconfig.get_config_var('SO')" works
>> on Linux, Windows and Mac.
>> I've tried to explain this twice already. You have both "
> multiarray.cpython-32mu.so" and "liblapack.so" (or some other library like
> that) on your system. The extension of both is needed, and always obtained
> via get_config_var('SO'). See the problem?
> If someone knows a better way to do this, I'm all for it. But I don't see a
> simpler way.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion