[Numpy-discussion] ANN: Numpy 1.6.1 release candidate 1
Mon Jun 20 09:20:16 CDT 2011
On 06/19/2011 05:21 AM, Ralf Gommers wrote:
> On Tue, Jun 14, 2011 at 5:28 AM, Bruce Southey <email@example.com
> <mailto:firstname.lastname@example.org>> wrote:
> On Mon, Jun 13, 2011 at 8:31 PM, Pauli Virtanen <email@example.com
> <mailto:firstname.lastname@example.org>> wrote:
> > On Mon, 13 Jun 2011 11:08:18 -0500, Bruce Southey wrote:
> > [clip]
> >> OSError:
> >> open shared object file: No such file or directory
> > I think that's a result of Python 3.2 changing the extension module
> > file naming scheme (IIRC to a versioned one).
> > The '.pyd' ending and its Unix counterpart are IIRC hardcoded to the
> > failing test, or some support code in Numpy. Clearly, they
> should instead
> > ask Python how it names the extensions modules. This information
> may be
> > available somewhere in the `sys` module.
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org <mailto:NumPy-Discussion@scipy.org>
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> I am impressed yet again!
> It really saved a lot of time to understand the reason.
> A quick comparison between Python versions:
> Python2.7: multiarray.so
> Python3.2: multiarray.cpython-32m.so
> Search for the extension leads to PEP 3149
> That looked familiar:
> This is POSIX only which excludes windows. I tracked it down to the
> list 'libname_ext' defined in file "numpy/ctypeslib.py" line 100:
> libname_ext = ['%s.so' % libname, '%s.pyd' % libname]
> On my 64-bit Linux system, I get the following results:
> $ python2.4 -c "from distutils import sysconfig; print
> $ python2.5 -c "from distutils import sysconfig; print
> $ python2.7 -c "from distutils import sysconfig; print
> $ python3.1 -c "from distutils import sysconfig;
> $ python3.2 -c "from distutils import sysconfig;
> My Windows 32-bit Python2.6 install:
> >>> from distutils import sysconfig
> >>> sysconfig.get_config_var('SO')
> Making the bug assumption that other OSes including 32-bit and 64-bit
> versions also provide the correct suffix, this suggest adding the
> import and modification as:
> import from distutils import sysconfig
> libname_ext = ['%s%s' % (libname, sysconfig.get_config_var('SO'))]
> Actually if that works for Mac, Sun etc. then 'load_library' function
> could be smaller.
> The issue is that libraries built as Python extensions have the extra
> ".cpython-mu32", but other libraries on your system don't. And
> sysconfig.get_config_var('SO') is used for both. I don't see another
> config var that allows to distinguish between the two. Unless on
> platforms where it matters there are separate return values in
> sysconfig.get_config_vars('SO'). What do you get for that on Linux?
> The logic of figuring out the right extension string should not be
> duplicated, distutils.misc_util seems like a good place for it. Can
> you test if this works for you:
> Finally the test_basic2 in "tests/test_ctypeslib.py" needs to be
> changed as well because it is no longer correct. Just commenting out
> the 'fix' appears to work.
> It works in the case of trying to load multiarray, but the function
> under test would still be broken.
> NumPy-Discussion mailing list
So how do I get these changes and apply them to the release candidate?
(This part of the development/test workflow needs some attention.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion