Mailman 3 February 2019 - SciPy-Dev

NumPy 1.16.2 released.
by Charles R Harris 26 Feb '19

26 Feb '19

Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.16.2. This is a quick release fixing several problems encountered on Windows. The Python versions supported are 2.7 and 3.5-3.7. The Windows problems addressed are: - DLL load problems for NumPy wheels on Windows, - distutils command line parsing on Windows. There is also a regression fix correcting signed zeros produced by divmod, see the release notes for details. Downstream developers building this release should use Cython >= 0.29.2 and, if using OpenBLAS, OpenBLAS > v0.3.4. If you are installing using pip, you may encounter a problem with older installed versions of NumPy that pip did not delete becoming mixed with the current version, resulting in an ``ImportError``. That problem is particularly common on Debian derived distributions due to a modified pip. The fix is to make sure all previous NumPy versions installed by pip have been removed. See #12736 <https://github.com/numpy/numpy/issues/12736> for discussion of the issue. Wheels for this release can be downloaded from PyPI <https://pypi.org/project/numpy/1.16.2/>, source archives and release notes are available from Github <https://github.com/numpy/numpy/releases/tag/v1.16.2>. *Contributors* A total of 5 people contributed to this release. People with a "+" by their names contributed a patch for the first time. * Charles Harris * Eric Wieser * Matti Picus * Tyler Reddy * Tony LaTorre + *Pull requests merged* A total of 7 pull requests were merged for this release. * #12909: TST: fix vmImage dispatch in Azure * #12923: MAINT: remove complicated test of multiarray import failure mode * #13020: BUG: fix signed zero behavior in npy_divmod * #13026: MAINT: Add functions to parse shell-strings in the platform-native... * #13028: BUG: Fix regression in parsing of F90 and F77 environment variables * #13038: BUG: parse shell escaping in extra_compile_args and extra_link_args * #13041: BLD: Windows absolute path DLL loading Cheers, Charles Harris

1 0

ANN: SciPy 1.2.1
by Tyler Reddy 13 Feb '19

13 Feb '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.2.1, which is a bug fix release. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.2.1 One of a few ways to install this release with pip: pip install scipy==1.2.1 ========================== SciPy 1.2.1 Release Notes ========================== SciPy 1.2.1 is a bug-fix release with no new features compared to 1.2.0. Most importantly, it solves the issue that 1.2.0 cannot be installed from source on Python 2.7 because of non-ASCII character issues. It is also notable that SciPy 1.2.1 wheels were built with OpenBLAS 0.3.5.dev, which may alleviate some linear algebra issues observed in SciPy 1.2.0. Authors ======= * Eric Larson * Mark Mikofski * Evgeni Burovski * Ralf Gommers * Eric Moore * Tyler Reddy Issues closed for 1.2.1 ------------------------ * `#9606 <https://github.com/scipy/scipy/issues/9606>`__: SyntaxError: Non-ASCII character '\xe2' in file scipy/stats/_continuous_distns.py on line 3346, but no encoding declared * `#9608 <https://github.com/scipy/scipy/issues/9608>`__: Version 1.2.0 introduces `too many indices for array` error in... * `#9709 <https://github.com/scipy/scipy/issues/9709>`__: scipy.stats.gaussian_kde normalizes the weights keyword argument... * `#9733 <https://github.com/scipy/scipy/issues/9733>`__: scipy.linalg.qr_update gives NaN result * `#9724 <https://github.com/scipy/scipy/issues/9724>`__: CI: Is scipy.scipy Windows Python36-32bit-full working? Pull requests for 1.2.1 ------------------------ * `#9612 <https://github.com/scipy/scipy/pull/9612>`__: BUG: don't use array newton unless size is greater than 1 * `#9615 <https://github.com/scipy/scipy/pull/9615>`__: ENH: Add test for encoding * `#9720 <https://github.com/scipy/scipy/pull/9720>`__: BUG: stats: weighted KDE does not modify the weights array * `#9739 <https://github.com/scipy/scipy/pull/9739>`__: BUG: qr_updates fails if u is exactly in span Q * `#9725 <https://github.com/scipy/scipy/pull/9725>`__: TST: pin mingw for Azure Win CI * `#9736 <https://github.com/scipy/scipy/pull/9736>`__: TST: adjust to vmImage dispatch in Azure * `#9681 <https://github.com/scipy/scipy/pull/9681>`__: BUG: Fix failing stats tests (partial backport) * `#9662 <https://github.com/scipy/scipy/pull/9662>`__: TST: interpolate: avoid pytest deprecations Checksums ========= MD5 ~~~ 982810997da9daab2e512a6c27918889 scipy-1.2.1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 9500cad49b7eac9786c90cba146ad357 scipy-1.2.1-cp27-cp27m-manylinux1_i686.whl fe9ba7f16e0e7f7c9cd59d39ea8e9545 scipy-1.2.1-cp27-cp27m-manylinux1_x86_64.whl f1823b26b2afda2027f78df427791700 scipy-1.2.1-cp27-cp27m-win32.whl c0692c60b4baaafd99fb2bf0c689bbf1 scipy-1.2.1-cp27-cp27m-win_amd64.whl b5a5b9b146bac064a7921c5121d5e19c scipy-1.2.1-cp27-cp27mu-manylinux1_i686.whl fd637f4dc4308ae9cf7655e3e5f3a27d scipy-1.2.1-cp27-cp27mu-manylinux1_x86_64.whl 8faae90250009230cd2f7845ba4735f2 scipy-1.2.1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl a28a93cb20987666f788d43c50e2ab79 scipy-1.2.1-cp34-cp34m-manylinux1_i686.whl 26264ebb568728065e3ef73b5419793a scipy-1.2.1-cp34-cp34m-manylinux1_x86_64.whl fbb79da3d5823ba0f23b0f8d50023bfd scipy-1.2.1-cp34-cp34m-win32.whl f82cf6834e4e2a2e4008fec5da2f4b0b scipy-1.2.1-cp34-cp34m-win_amd64.whl cc248fd969b11589d98bcb550330e08d scipy-1.2.1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 3b5e8eb89a49fb7bc506cf17a54b926b scipy-1.2.1-cp35-cp35m-manylinux1_i686.whl 0cd66785fd9f8390494f42beb499f56a scipy-1.2.1-cp35-cp35m-manylinux1_x86_64.whl 379d37ae932af2096e037b4defd4cf60 scipy-1.2.1-cp35-cp35m-win32.whl 5dd4c47c501c96dc0c20b72521058133 scipy-1.2.1-cp35-cp35m-win_amd64.whl 6fa013443295e55c96eb174578dcffee scipy-1.2.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 5069317ab38e3dfbb8923341c2b23a69 scipy-1.2.1-cp36-cp36m-manylinux1_i686.whl 8e6a1fd1354428074d8457fe46cd4f7c scipy-1.2.1-cp36-cp36m-manylinux1_x86_64.whl 27142bff898a18368032165c27c11466 scipy-1.2.1-cp36-cp36m-win32.whl 489fd885aefd07bded69a8e0452c16b0 scipy-1.2.1-cp36-cp36m-win_amd64.whl 84ef33013d9871f23db0ecad25552636 scipy-1.2.1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 7b7ae846b70e60188b3d772e9d60d3d2 scipy-1.2.1-cp37-cp37m-manylinux1_i686.whl 21b29788cd2c037366d2ff5d54ae7517 scipy-1.2.1-cp37-cp37m-manylinux1_x86_64.whl e11ce933d012481ea27fe49314b606aa scipy-1.2.1-cp37-cp37m-win32.whl 23424815af8e69f945bb406a0c1be6c6 scipy-1.2.1-cp37-cp37m-win_amd64.whl fe88877767563e50078df86dadf7b1f4 scipy-1.2.1.tar.gz 312110f3ea37269003e587207eb72855 scipy-1.2.1.tar.xz b4e2b70f7885a746618e8bcdf77857d7 scipy-1.2.1.zip SHA256 ~~~~~~ f06819b028b8ef9010281e74c59cb35483933583043091ed6b261bb1540f11cc scipy-1.2.1-cp27-cp27m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 70e37cec0ac0fe95c85b74ca4e0620169590fd5d3f44765f3c3a532cedb0e5fd scipy-1.2.1-cp27-cp27m-manylinux1_i686.whl 9726791484f08e394af0b59eb80489ad94d0a53bbb58ab1837dcad4d58489863 scipy-1.2.1-cp27-cp27m-manylinux1_x86_64.whl 790cbd3c8d09f3a6d9c47c4558841e25bac34eb7a0864a9def8f26be0b8706af scipy-1.2.1-cp27-cp27m-win32.whl 014cb900c003b5ac81a53f2403294e8ecf37aedc315b59a6b9370dce0aa7627a scipy-1.2.1-cp27-cp27m-win_amd64.whl 78e12972e144da47326958ac40c2bd1c1cca908edc8b01c26a36f9ffd3dce466 scipy-1.2.1-cp27-cp27mu-manylinux1_i686.whl f15f2d60a11c306de7700ee9f65df7e9e463848dbea9c8051e293b704038da60 scipy-1.2.1-cp27-cp27mu-manylinux1_x86_64.whl e2cfcbab37c082a5087aba5ff00209999053260441caadd4f0e8f4c2d6b72088 scipy-1.2.1-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl b86ae13c597fca087cb8c193870507c8916cefb21e52e1897da320b5a35075e5 scipy-1.2.1-cp34-cp34m-manylinux1_i686.whl 865afedf35aaef6df6344bee0de391ee5e99d6e802950a237f9fb9b13e441f91 scipy-1.2.1-cp34-cp34m-manylinux1_x86_64.whl e742f1f5dcaf222e8471c37ee3d1fd561568a16bb52e031c25674ff1cf9702d5 scipy-1.2.1-cp34-cp34m-win32.whl f6b88c8d302c3dac8dff7766955e38d670c82e0d79edfc7eae47d6bb2c186594 scipy-1.2.1-cp34-cp34m-win_amd64.whl 7274735fb6fb5d67d3789ddec2cd53ed6362539b41aa6cc0d33a06c003aaa390 scipy-1.2.1-cp35-cp35m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 963815c226b29b0176d5e3d37fc9de46e2778ce4636a5a7af11a48122ef2577c scipy-1.2.1-cp35-cp35m-manylinux1_i686.whl 281a34da34a5e0de42d26aed692ab710141cad9d5d218b20643a9cb538ace976 scipy-1.2.1-cp35-cp35m-manylinux1_x86_64.whl 5a10661accd36b6e2e8855addcf3d675d6222006a15795420a39c040362def66 scipy-1.2.1-cp35-cp35m-win32.whl def0e5d681dd3eb562b059d355ae8bebe27f5cc455ab7c2b6655586b63d3a8ea scipy-1.2.1-cp35-cp35m-win_amd64.whl 79792c8fe8e9d06ebc50fe23266522c8c89f20aa94ac8e80472917ecdce1e5ba scipy-1.2.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 6dcc43a88e25b815c2dea1c6fac7339779fc988f5df8396e1de01610604a7c38 scipy-1.2.1-cp36-cp36m-manylinux1_i686.whl f31338ee269d201abe76083a990905473987371ff6f3fdb76a3f9073a361cf37 scipy-1.2.1-cp36-cp36m-manylinux1_x86_64.whl 9de84a71bb7979aa8c089c4fb0ea0e2ed3917df3fb2a287a41aaea54bbad7f5d scipy-1.2.1-cp36-cp36m-win32.whl b2c324ddc5d6dbd3f13680ad16a29425841876a84a1de23a984236d1afff4fa6 scipy-1.2.1-cp36-cp36m-win_amd64.whl 588f9cc4bfab04c45fbd19c1354b5ade377a8124d6151d511c83730a9b6b2338 scipy-1.2.1-cp37-cp37m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl 628f60be272512ca1123524969649a8cb5ae8b31cca349f7c6f8903daf9034d7 scipy-1.2.1-cp37-cp37m-manylinux1_i686.whl 870fd401ec7b64a895cff8e206ee16569158db00254b2f7157b4c9a5db72c722 scipy-1.2.1-cp37-cp37m-manylinux1_x86_64.whl d78702af4102a3a4e23bb7372cec283e78f32f5573d92091aa6aaba870370fe1 scipy-1.2.1-cp37-cp37m-win32.whl ba0488d4dbba2af5bf9596b849873102d612e49a118c512d9d302ceafa36e01a scipy-1.2.1-cp37-cp37m-win_amd64.whl e085d1babcb419bbe58e2e805ac61924dac4ca45a07c9fa081144739e500aa3c scipy-1.2.1.tar.gz be0e1b322b4b9f2ab88a35db32c494f12639937cf671d4cc210238feb8d5a89d scipy-1.2.1.tar.xz 8140810cf19707c732f330ba6e54968bc85160768850bfbf38d995193e597e2e scipy-1.2.1.zip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJcXk5KAAoJELD/41ZX0J71zZ0P/3/6ZgXpYGEA013LKNh+/PrV YSA2G7b4jGYExim4cgFHDrwBPoFwiVcfdBTPMxSYn8mtvuqyn4TlcmxqGKQkOwoS zdOEUHdxPFLt8nAy5rWjiCYHzC4qCpGnt+3ROVzRjGA2BLSdzqBg+njT2+9FKNrH 5UoZP4s3TCA8Yn4z2bYV+2viHTAXFsEhHFraNuK5MQu045E57gt5VwYm+ylEeE3Q npcO2U8vio7Hr8ARVOyvQqL8HsQy5/8q8lGTBLbBAP+ujPXi3lRwdb2KqPl3ojfE 7afkEdC3W44CCxPoJfLOdwFnsaOUGVtFeNKmcS2YNWregMpjeG68AjjHO1vCeM34 twNXrwhO2gROwYnp6Q22TTiMsPTTUvce+qGmAyD1d4osOG5zz1A/YQWxHw8Runl0 LPrVt46aOUJTvjCAFs6c7McY04j6lILMyGZlxpyGwLEkP9YAABGvbOtHDMBBWvJs CFxLAo4gEWfJKcJ0bnAKQ9HNeJ45JJ3PQLD5eEmOl+TOQjl0nzY4c7D4LYB0wpl2 NY7tr/TcASX7TlwbjzmlccJUDmNhekcZVTbx65NFjmb2/nUgqAB9ZVjJKyQDpZng rLXZitBmd8IRb8xXp5Smbgt0VccwbMfJF4fulnrVokwILhsIbwZlYQDCG6KOPV27 mObh7S2ZazRQ76Gd4rcu =HBJ8 -----END PGP SIGNATURE-----

4 3

Regarding GSoC 2019 Project
by Amarnath Karthi 08 Feb '19

08 Feb '19

Hey, I am a final year undergrad student planning to do my GSoC under Scipy. I have an experience with: - Python 3 - Scientific computing I also am currently working on improving the performance of Cooley Tukey FFT on distributed systems. Thus I think I will be a good fit for the project. I would like to know whether this project will require me to have an indepth knowledge of the FFT Packages written in C or FORTRAN? Or that can be learnt on the fly? Also how should I proceed ahead? Regards, Amarnath

2 1

SciPy 1.2.0 release schedule
by Tyler Reddy 07 Feb '19

07 Feb '19

Hi all, It is almost 6 months after the 1.1.0 release on May 5, so probably time to plan the 1.2.0 release. It would be a good idea to look over the PRs with a 1.2.0 milestone <https://github.com/scipy/scipy/pulls?q=is%3Aopen+is%3Apr+milestone%3A1.2.0>, and tag anything else that should have this milestone appropriately. I'd like to propose the following schedule: Nov. 5: branch 1.2.x Nov. 8: rc1 Nov. 21: rc2 (if needed) Nov. 30: final release Thoughts? Best wishes, Tyler

5 25

SciPy GSoC'15 participation?
by Ralf Gommers 06 Feb '19

06 Feb '19

Hi all, It's the time of the year where GSoC kicks off again. Below email from Terri, the lead PSF organizer, explains some of the deadlines and things that are different from last year. So: do we want to participate again this year? We already have one serious proposal from a student in preparation, about scipy.fftpack (see earlier thread on this list). If we do want to participate, do we have volunteers for mentors and a sub-org admin? I've done the latter for the last years, but this year I really do not have the time (if you're interested: it doesn't take much time compared to mentoring). Cheers, Ralf ---------- Forwarded message --------- From: Terri Oda <terri(a)toybox.ca> Date: Tue, Jan 1, 2019 at 11:02 PM Subject: [GSoC-mentors] Python in GSoC 2019! To: <gsoc-mentors(a)python.org> Happy new year, everyone! As you may have seen, we're starting to prepare Python's application for GSoC 2019, and we need your ideas. We've got a few eager students already asking what you'd like them to work on. The website has been updated for 2019: http://python-gsoc.org New and notable: - GSoC org applications open early this year, starting January 15th! Google moves the dates around every year so students in different countries with different schedules get opportunities to participate more easily when the times line up with their scholastic year, and this is one of the early years. - We're asking for sub-orgs to get as many ideas ready as they can by Feb 4th so that we have lots of ideas ready for when Google judges our umbrella org ideas page. We need well-formed ideas if we want to get accepted, and now's a great time to catch the eye of the most eager students! Once you've got some ideas ready, you can make a pull request to get yourself added to the page here: https://github.com/python-gsoc/python-gsoc.github.io - John has set up a Slack channel for Python GSoC. It's bridged in to link to the IRC channel, but may be a more familiar interface/mobile app for people who aren't regular IRC users. I know, it's not open source, but we didn't have much luck with Zulip and while Matrix has been good it's not quite solving the usability problem we have with the students, so we're trying out the more popular Slack. We'll see how it works this year and if it's worth keeping, so if this is a thing you want us to support, please use it! (And if you see problems, please report them to gsoc-admins(a)python.org so we can get them fixed.) You can snag a Slack invite here: https://join.slack.com/t/python-gsoc/shared_invite/enQtNDg0NDgwNjMyNTE2LTNl… - We've got space for some new sub-orgs this year! If you know of any projects that might want to try out GSoC with us this year, let us know, or tell them to email gsoc-admins(a)python.org (or join irc/matrix/slack, or whatever) to chat with us! Terri _______________________________________________ GSoC-mentors mailing list GSoC-mentors(a)python.org https://mail.python.org/mailman/listinfo/gsoc-mentors

3 4

curve_fit() should require initial values for parameters
by Matt Newville 03 Feb '19

03 Feb '19

Hi All, First, I apologize in advance if this sounds un-appreciative of the efforts made in scipy and scipy.optimize. I am a very big fan, and very appreciative of the work done here. With lmfit we have tried to take the "rough edges" from optimization and curve-fitting with python, but we're very much in favor of building wrappers on top of the core of scipy.optimize. Still, many people use `curve_fit` because it comes built-in with scipy, is well advertised, and is well-suited for simple uses. It is clearly aimed at novices and tries to hide many of the complexities of using optimization routines for curve fitting. I try to help people with questions about using `curve_fit` and `scipy.optimize` as well as `lmfit`. In trying to help people using `curve_fit`, I've noticed a disturbing trend. When a novice or even experienced user asks for help using `curve_fit` because a fit "doesn't work" there is a very good chance that they did not specify `p0` for the initial values and that the default behavior of setting all starting values to 1.0 will cause their fit to fail to converge, or really to even start. This failure is understandable to an experienced user, but apparently not to the novice. Curve-fitting problems are by nature local solvers and are always sensitive to initial values. For some problems, parameter values of 1.0 are simply inappropriate, and the numerical derivatives for some parameters near values of 1.0 will be 0. Indeed, there is no value that is always a reasonable starting value for all parameters. FWIW, in lmfit, we simply refuse to let a user run a curve-fitting problem without initial values. I believe that most other curve-fitting interfaces also require initial values for all parameters. Unfortunately, faced with no initial parameter values, `curve_fit` silently chooses initial values. It doesn't try to make an informed decision, it simply chooses '1.0', which can easily be so far off as to prevent a solution from being found. When this happens, `curve_fit` gives no information to the user of what the problem is. Indeed it allows initial values to not be set, giving the impression that they are not important. This impression is wrong: initial values are always important. `curve_fit` is mistaken in having a default starting value. I've made a Pull Request at https://github.com/scipy/scipy/pull/9701 to fix this misbehavior, so that `curve_fit()` requires starting values. It was suggested there that this topic should be discussed here. I'm happy to do so. It was suggested in the github Issue that forcing the user to give initial values was "annoying". It was also suggested that a deprecation cycle would be required. I should say that I don't actually use `curve_fit()` myself, I'm just trying to help make this commonly used routine be completely wrong less often. Cheers, --Matt Newville

13 35

Discussion on backend system for scipy.fftpack
by Sourav Singh 03 Feb '19

03 Feb '19

Hello, I am writing the mail to start a discussion on the backend system for scipy.fftpack. I am currently looking into ways of implementing a backend system and have found that the Keras library's method for backend to be elegant. The Keras library maintains separate modules for each backend, which has their own classes and functions for operations and session creation. The default backend can be set up through a configuration or a flag of some kind. So far we have numpy.fft, scipy.fftpack, pyFFTW and cupy(I am not sure about having this) for FFT ops. I would like to discuss further about the decisions on the kind of backend system that would be required so I can design a document containing class diagrams and such. Thanks for taking the time to read my email and have a great day! Regards, Sourav

2 1

mac osx blas segfault
by Mark Alexander Mikofski 03 Feb '19

03 Feb '19

Hi, Sorry for asking again. I know that Accelerate lapack has been deprecated. I have openblas from homebrew. If I use LDFLAGS, CPPFLAGS, and PKG_CONFIG_PATH , I get a very long traceback of compiler errors, I can post them if that helps. Without the flags, I get a segfault at test_cython_blas. I am prepending the flags inline to runtest.py instead of exporting them, if that makes a difference. Is there any document or quick guide that explains how to use runtest.py on mac osx? I've searched online but I haven't found a solution. Thanks! PS Anyone know how to search the mail list archives?

2 1

NumPy 1.16.1 release
by Charles R Harris 01 Feb '19

01 Feb '19

Hi All, On behalf of the NumPy team I'm pleased to announce the release of NumPy 1.16.1. This release fixes bugs reported against the 1.16.0 release, and also backports several enhancements from master that seem appropriate for a release series that is the last to support Python 2.7. The supported Python versions are 2.7 and 3.5-3.7. The wheels on PyPI are linked with OpenBLAS v0.3.4+, which should fix the known threading issues found in previous OpenBLAS versions. Downstream developers building this release should use Cython >= 0.29.2 and, if using OpenBLAS, OpenBLAS > v0.3.4. If you are installing using pip, you may encounter a problem with older installed versions of NumPy that pip did not delete becoming mixed with the current version, resulting in an *ImportError*. That problem is particularly common on Debian derived distributions due to a modified pip. The fix is to make sure all previous NumPy versions installed by pip have been removed. See #12736 <https://github.com/numpy/numpy/issues/12736> for discussion of the issue. Note that previously this problem resulted in an *AttributeError*. Wheels for this release can be downloaded from PyPI <https://pypi.org/project/numpy/1.16.1/>, source archives and release notes are available from Github <https://github.com/numpy/numpy/releases/tag/v1.16.1>. *Enhancements* * #12767: ENH: add mm->q floordiv * #12768: ENH: port np.core.overrides to C for speed * #12769: ENH: Add np.ctypeslib.as_ctypes_type(dtype), improve `np.ctypeslib.as_ctypes` * #12773: ENH: add "max difference" messages to np.testing.assert_array_equal... * #12820: ENH: Add mm->qm divmod * #12890: ENH: add _dtype_ctype to namespace for freeze analysis *Contributors* A total of 16 people contributed to this release. People with a "+" by their names contributed a patch for the first time. * Antoine Pitrou * Arcesio Castaneda Medina + * Charles Harris * Chris Markiewicz + * Christoph Gohlke * Christopher J. Markiewicz + * Daniel Hrisca + * EelcoPeacs + * Eric Wieser * Kevin Sheppard * Matti Picus * OBATA Akio + * Ralf Gommers * Sebastian Berg * Stephan Hoyer * Tyler Reddy Cheers, Charles Harris

1 0