[Numpy-discussion] ANN: Numpy 1.6.1 release candidate 1
Tue Jun 21 21:31:30 CDT 2011
On Tue, Jun 21, 2011 at 3:52 PM, Ralf Gommers
> On Tue, Jun 21, 2011 at 10:05 PM, Ralf Gommers <firstname.lastname@example.org>
>> 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>
>>>> So what is the actual name of the multiarray shared library with the
>>>> 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.
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.
More information about the NumPy-Discussion