[Numpy-discussion] ANN: Numpy 1.6.1 release candidate 1

[Bruce Southey]

On Tue, Jun 21, 2011 at 3:52 PM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Tue, Jun 21, 2011 at 10:05 PM, Ralf Gommers <ralf.gommers at googlemail.com>
> wrote:
>>
>>
>> On Tue, Jun 21, 2011 at 4:38 PM, Bruce Southey <bsouthey at gmail.com> wrote:
>>>
>>> On 06/21/2011 01:01 AM, Ralf Gommers wrote:
>>>
>>> On Tue, Jun 21, 2011 at 3:55 AM, Bruce Southey <bsouthey at gmail.com>
>>> 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.
>>>
>>> Ralf
>>>
>>>
>>> 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:
> https://github.com/rgommers/numpy/tree/sharedlibext
> Does that look better?
>
> Ralf
>
>>
>>
>>>
>>> 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.
>>
>> Cheers,
>> Ralf
>>

Okay, I see what you are getting at:
There are various Python bindings/interface to C libraries (Fortran in
Scipy) such as lapack and atlas created by a non-Python source but
there is also an 'shared library' created with Python as part of an
extension. The PEP does not appear to differentiate between these -
probably because it assumes non-Python libraries are loaded
differently (ctypes is Python 2.5+). So there has to be a different
way to find the extension.


Bruce