{"action":"opened","number":282,"pull_request":{"url":"https://api.github.com/repos/cggh/scikit-allel/pulls/282","id":303438660,"node_id":"MDExOlB1bGxSZXF1ZXN0MzAzNDM4NjYw","html_url":"https://github.com/cggh/scikit-allel/pull/282","diff_url":"https://github.com/cggh/scikit-allel/pull/282.diff","patch_url":"https://github.com/cggh/scikit-allel/pull/282.patch","issue_url":"https://api.github.com/repos/cggh/scikit-allel/issues/282","number":282,"state":"open","locked":false,"title":"Scheduled monthly dependency update for August","user":{"login":"pyup-bot","id":16239342,"node_id":"MDQ6VXNlcjE2MjM5MzQy","avatar_url":"https://avatars0.githubusercontent.com/u/16239342?v=4","gravatar_id":"","url":"https://api.github.com/users/pyup-bot","html_url":"https://github.com/pyup-bot","followers_url":"https://api.github.com/users/pyup-bot/followers","following_url":"https://api.github.com/users/pyup-bot/following{/other_user}","gists_url":"https://api.github.com/users/pyup-bot/gists{/gist_id}","starred_url":"https://api.github.com/users/pyup-bot/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pyup-bot/subscriptions","organizations_url":"https://api.github.com/users/pyup-bot/orgs","repos_url":"https://api.github.com/users/pyup-bot/repos","events_url":"https://api.github.com/users/pyup-bot/events{/privacy}","received_events_url":"https://api.github.com/users/pyup-bot/received_events","type":"User","site_admin":false},"body":"\n\n\n\n\n### Update [cython](https://pypi.org/project/cython) from **0.29.10** to **0.29.13**.\n\n\n<details>\n  <summary>Changelog</summary>\n  \n  \n   ### 0.29.13\n   ```\n   ====================\n\nBugs fixed\n----------\n\n* A reference leak for ``None`` was fixed when converting a memoryview\n  to a Python object.  (Github issue 3023)\n\n* The declaration of ``PyGILState_STATE`` in ``cpython.pystate`` was unusable.\n  Patch by Kirill Smelkov.  (Github issue 2997)\n\nOther changes\n-------------\n\n* The declarations in ``posix.mman`` were extended.\n  Patches by Kirill Smelkov.  (Github issues 2893, 2894, 3012)\n   ```\n   \n  \n  \n   ### 0.29.12\n   ```\n   ====================\n\nBugs fixed\n----------\n\n* Fix compile error in CPython 3.8b2 regarding the ``PyCode_New()`` signature.\n  (Github issue 3031)\n\n* Fix a C compiler warning about a missing ``int`` downcast.\n  (Github issue 3028)\n\n* Fix reported error positions of undefined builtins and constants.\n  Patch by Orivej Desh.  (Github issue 3030)\n\n* A 32 bit issue in the Pythran support was resolved.\n  Patch by Serge Guelton.  (Github issue 3032)\n   ```\n   \n  \n  \n   ### 0.29.11\n   ```\n   ====================\n\nBugs fixed\n----------\n\n* Fix compile error in CPython 3.8b2 regarding the ``PyCode_New()`` signature.\n  Patch by Nick Coghlan. (Github issue 3009)\n\n* Invalid C code generated for lambda functions in cdef methods.\n  Patch by Josh Tobin.  (Github issue 2967)\n\n* Support slice handling in newer Pythran versions.\n  Patch by Serge Guelton.  (Github issue 2989)\n\n* A reference leak in power-of-2 calculation was fixed.\n  Patch by Sebastian Berg.  (Github issue 3022)\n\n* The search order for include files was changed. Previously it was\n  ``include_directories``, ``Cython/Includes``, ``sys.path``. Now it is\n  ``include_directories``, ``sys.path``, ``Cython/Includes``. This was done to\n  allow third-party ``*.pxd`` files to override the ones in Cython.\n  Original patch by Matti Picus.  (Github issue 2905)\n\n* Setting ``language_level=2`` in a file did not work if ``language_level=3``\n  was enabled globally before.\n  Patch by Jeroen Demeyer.  (Github issue 2791)\n   ```\n   \n  \n</details>\n\n\n \n\n<details>\n  <summary>Links</summary>\n  \n  - PyPI: https://pypi.org/project/cython\n  - Changelog: https://pyup.io/changelogs/cython/\n  - Homepage: http://cython.org/\n</details>\n\n\n\n\n\n### Update [numpy](https://pypi.org/project/numpy) from **1.16.4** to **1.17.0**.\n\n\n<details>\n  <summary>Changelog</summary>\n  \n  \n   ### 1.17.0\n   ```\n   ==========================\n\nThis NumPy release contains a number of new features that should substantially\nimprove its performance and usefulness, see Highlights below for a summary. The\nPython versions supported are 3.5-3.7, note that Python 2.7 has been dropped.\nPython 3.8b1 should work with the released source packages, but there are no\nfuture guarantees.\n\nDownstream developers should use Cython &gt;= 0.29.10 for Python 3.8 support and\nOpenBLAS &gt;= 3.7 (not currently out) to avoid problems on the Skylake\narchitecture. The NumPy wheels on PyPI are built from the OpenBLAS development\nbranch in order to avoid those problems.\n\n\nHighlights\n==========\n\n* A new extensible random module along with four selectable random number\n  generators and improved seeding designed for use in parallel processes has\n  been added. The currently available bit generators are MT19937, PCG64,\n  Philox, and SFC64. See below under New Features.\n\n* NumPy&#39;s FFT implementation was changed from fftpack to pocketfft, resulting\n  in faster, more accurate transforms and better handling of datasets of\n  prime length. See below under Improvements.\n\n* New radix sort and timsort sorting methods. It is currently not possible to\n  choose which will be used, but they are hardwired to the datatype and used\n  when either ``stable`` or ``mergesort`` is passed as the method. See below\n  under Improvements.\n\n* Overriding numpy functions is now possible by default,\n  see ``__array_function__`` below.\n\n\nNew functions\n=============\n\n* `numpy.errstate` is now also a function decorator\n\n\nDeprecations\n============\n\n``np.polynomial`` functions warn when passed ``float`` in place of ``int``\n--------------------------------------------------------------------------\nPreviously functions in this module would accept ``float`` values provided they\nwere integral (``1.0``, ``2.0``, etc). For consistency with the rest of numpy,\ndoing so is now deprecated, and in future will raise a ``TypeError``.\n\nSimilarly, passing a float like ``0.5`` in place of an integer will now raise a\n``TypeError`` instead of the previous ``ValueError``.\n\nDeprecate ``numpy.distutils.exec_command`` and ``numpy.distutils.temp_file_name``\n---------------------------------------------------------------------------------\nThe internal use of these functions has been refactored and there are better\nalternatives. Relace ``exec_command`` with `subprocess.Popen` and\n``temp_file_name`` with `tempfile.mkstemp`.\n\nWriteable flag of C-API wrapped arrays\n--------------------------------------\nWhen an array is created from the C-API to wrap a pointer to data, the only\nindication we have of the read-write nature of the data is the ``writeable``\nflag set during creation. It is dangerous to force the flag to writeable.\nIn the future it will not be possible to switch the writeable flag to ``True``\nfrom python.\nThis deprecation should not affect many users since arrays created in such\na manner are very rare in practice and only available through the NumPy C-API.\n\n`numpy.nonzero` should no longer be called on 0d arrays\n-------------------------------------------------------\nThe behavior of nonzero on 0d arrays was surprising, making uses of it almost\nalways incorrect. If the old behavior was intended, it can be preserved without\na warning by using ``nonzero(atleast_1d(arr))`` instead of ``nonzero(arr)``.\nIn a future release, it is most likely this will raise a `ValueError`.\n\nWriting to the result of `numpy.broadcast_arrays` will warn\n-----------------------------------------------------------\n\nCommonly `numpy.broadcast_arrays` returns a writeable array with internal\noverlap, making it unsafe to write to. A future version will set the\n``writeable`` flag to ``False``, and require users to manually set it to\n``True`` if they are sure that is what they want to do. Now writing to it will\nemit a deprecation warning with instructions to set the ``writeable`` flag\n``True``.  Note that if one were to inspect the flag before setting it, one\nwould find it would already be ``True``.  Explicitly setting it, though, as one\nwill need to do in future versions, clears an internal flag that is used to\nproduce the deprecation warning. To help alleviate confusion, an additional\n`FutureWarning` will be emitted when accessing the ``writeable`` flag state to\nclarify the contradiction.\n\n\nFuture Changes\n==============\n\nShape-1 fields in dtypes won&#39;t be collapsed to scalars in a future version\n--------------------------------------------------------------------------\n\nCurrently, a field specified as ``[(name, dtype, 1)]`` or ``&quot;1type&quot;`` is\ninterpreted as a scalar field (i.e., the same as ``[(name, dtype)]`` or\n``[(name, dtype, ()]``). This now raises a FutureWarning; in a future version,\nit will be interpreted as a shape-(1,) field, i.e. the same as ``[(name,\ndtype, (1,))]`` or ``&quot;(1,)type&quot;`` (consistently with ``[(name, dtype, n)]``\n/ ``&quot;ntype&quot;`` with ``n&gt;1``, which is already equivalent to ``[(name, dtype,\n(n,)]`` / ``&quot;(n,)type&quot;``).\n\n\nCompatibility notes\n===================\n\nfloat16 subnormal rounding\n--------------------------\nCasting from a different floating point precision to float16 used incorrect\nrounding in some edge cases. This means in rare cases, subnormal results will\nnow be rounded up instead of down, changing the last bit (ULP) of the result.\n\nSigned zero when using divmod\n-----------------------------\nStarting in version 1.12.0, numpy incorrectly returned a negatively signed zero\nwhen using the ``divmod`` and ``floor_divide`` functions when the result was\nzero. For example::\n\n   &gt;&gt;&gt; np.zeros(10)//1\n   array([-0., -0., -0., -0., -0., -0., -0., -0., -0., -0.])\n\nWith this release, the result is correctly returned as a positively signed\nzero::\n\n   &gt;&gt;&gt; np.zeros(10)//1\n   array([0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])\n\n``MaskedArray.mask`` now returns a view of the mask, not the mask itself\n------------------------------------------------------------------------\nReturning the mask itself was unsafe, as it could be reshaped in place which\nwould violate expectations of the masked array code. It&#39;s behavior is now\nconsistent with the ``.data`` attribute, which also returns a view.\n\nThe underlying mask can still be accessed with ``._mask`` if it is needed.\nTests that contain ``assert x.mask is not y.mask`` or similar will need to be\nupdated.\n\nDo not lookup ``__buffer__`` attribute in `numpy.frombuffer`\n------------------------------------------------------------\nLooking up ``__buffer__`` attribute in `numpy.frombuffer` was undocumented and\nnon-functional. This code was removed. If needed, use\n``frombuffer(memoryview(obj), ...)`` instead.\n\n``out``is buffered for memory overlaps in ``np.take``, ``np.choose``, ``np.put``\n--------------------------------------------------------------------------------\nIf the out argument to these functions is provided and has memory overlap with\nthe other arguments, it is now buffered to avoid order-dependent behavior.\n\nUnpickling while loading requires explicit opt-in\n-------------------------------------------------\nThe functions ``np.load``, and ``np.lib.format.read_array`` take an\n``allow_pickle`` keyword which now defaults to ``False`` in response to\n`CVE-2019-6446 &lt;https://nvd.nist.gov/vuln/detail/CVE-2019-6446&gt;`_.\n\nPotential changes to the random stream in old random module\n-----------------------------------------------------------\nDue to bugs in the application of log to random floating point numbers,\nthe stream may change when sampling from ``np.random.beta``, ``np.random.binomial``,\n``np.random.laplace``, ``np.random.logistic``, ``np.random.logseries`` or\n``np.random.multinomial`` if a 0 is generated in the underlying MT19937 random stream.\nThere is a 1 in :math:`10^{53}` chance of this occurring, and so the probability that\nthe stream changes for any given seed is extremely small. If a 0 is encountered in the\nunderlying generator, then the incorrect value produced (either ``np.inf``\nor ``np.nan``) is now dropped.\n\n``i0`` now always returns a result with the same shape as the input\n-------------------------------------------------------------------\nPreviously, the output was squeezed, such that, e.g., input with just a single\nelement would lead to an array scalar being returned, and inputs with shapes\nsuch as ``(10, 1)`` would yield results that would not broadcast against the\ninput.\n\nNote that we generally recommend the SciPy implementation over the numpy one:\nit is a proper ufunc written in C, and more than an order of magnitude faster.\n\n``np.can_cast`` no longer assumes all unsafe casting is allowed\n---------------------------------------------------------------\nPreviously, ``can_cast`` returned `True` for almost all inputs for\n``casting=&#39;unsafe&#39;``, even for cases where casting was not possible, such as\nfrom a structured dtype to a regular one.  This has been fixed, making it\nmore consistent with actual casting using, e.g., the ``.astype`` method.\n\n``arr.writeable`` can be switched to true slightly more often\n-------------------------------------------------------------\n\nIn rare cases, it was not possible to switch an array from not writeable\nto writeable, although a base array is writeable. This can happen if an\nintermediate ``arr.base`` object is writeable. Previously, only the deepest\nbase object was considered for this decision. However, in rare cases this\nobject does not have the necessary information. In that case switching to\nwriteable was never allowed. This has now been fixed.\n\n\nC API changes\n=============\n\ndimension or stride input arguments are now passed by ``npy_intp const*``\n-------------------------------------------------------------------------\nPreviously these function arguments were declared as the more strict\n``npy_intp*``, which prevented the caller passing constant data.\nThis change is backwards compatible, but now allows code like::\n\n    npy_intp const fixed_dims[] = {1, 2, 3};\n    // no longer complains that the const-qualifier is discarded\n    npy_intp size = PyArray_MultiplyList(fixed_dims, 3);\n\n\nNew Features\n============\n\nNew extensible random module with selectable random number generators\n---------------------------------------------------------------------\nA new extensible random module along with four selectable random number\ngenerators and improved seeding designed for use in parallel processes has been\nadded. The currently available bit generators are MT19937, PCG64, Philox, and\nSFC64. PCG64 is the new default while MT19937 is retained for backwards\ncompatibility. Note that the legacy random module is unchanged and is now\nfrozen, your current results will not change. Extensive documentation for the\nnew module is available online at\n`NumPy devdocs &lt;http://www.numpy.org/devdocs/reference/random/index.html&gt;`_.\n\nlibFLAME\n--------\nSupport for building NumPy with the libFLAME linear algebra package as the LAPACK,\nimplementation, see\n`libFLAME &lt;https://www.cs.utexas.edu/~flame/web/libFLAME.html&gt;`_ for details.\n\nUser-defined BLAS detection order\n---------------------------------\n``numpy.distutils`` now uses an environment variable, comma-separated and case\ninsensitive, to determine the detection order for BLAS libraries.\nBy default ``NPY_BLAS_ORDER=mkl,blis,openblas,atlas,accelerate,blas``.\nHowever, to force the use of OpenBLAS simply do::\n\n   NPY_BLAS_ORDER=openblas python setup.py build\n\nwhich forces the use of OpenBLAS.\nThis may be helpful for users which have a MKL installation but wishes to try\nout different implementations.\n\nUser-defined LAPACK detection order\n-----------------------------------\n``numpy.distutils`` now uses an environment variable, comma-separated and case\ninsensitive, to determine the detection order for LAPACK libraries.\nBy default ``NPY_BLAS_ORDER=mkl,openblas,flame,atlas,accelerate,lapack``.\nHowever, to force the use of OpenBLAS simply do::\n\n   NPY_LAPACK_ORDER=openblas python setup.py build\n\nwhich forces the use of OpenBLAS.\nThis may be helpful for users which have a MKL installation but wishes to try\nout different implementations.\n\n``np.ufunc.reduce`` and related functions now accept a ``where`` mask\n---------------------------------------------------------------------\n``np.ufunc.reduce``, ``np.sum``, ``np.prod``, ``np.min``, ``np.max`` all\nnow accept a ``where`` keyword argument, which can be used to tell which\nelements to include in the reduction.  For reductions that do not have an\nidentity, it is necessary to also pass in an initial value (e.g.,\n``initial=np.inf`` for ``np.min``).  For instance, the equivalent of\n``nansum`` would be, ``np.sum(a, where=~np.isnan(a))``.\n\nTimsort and radix sort have replaced mergesort for stable sorting\n-----------------------------------------------------------------\nBoth radix sort and timsort have been implemented and are now used in place of\nmergesort. Due to the need to maintain backward compatibility, the sorting\n``kind`` options ``&quot;stable&quot;`` and ``&quot;mergesort&quot;`` have been made aliases of\neach other with the actual sort implementation depending on the array type.\nRadix sort is used for small integer types of 16 bits or less and timsort for\nthe remaining types.  Timsort features improved performace on data containing\nalready or nearly sorted data and performs like mergesort on random data and\nrequires O(n/2) working space.  Details of the timsort algorithm can be found\nat\n`CPython listsort.txt &lt;https://github.com/python/cpython/blob/3.7/Objects/listsort.txt&gt;`_.\n\n``np.unpackbits`` now accepts a ``count`` parameter\n---------------------------------------------------\n``count`` allows subsetting the number of bits that will be unpacked up-front,\nrather than reshaping and subsetting later, making the ``packbits`` operation\ninvertible, and the unpacking less wasteful. Counts larger than the number of\navailable bits add zero padding. Negative counts trim bits off the end instead\nof counting from the beginning. None counts implement the existing behavior of\nunpacking everything.\n\n``np.linalg.svd`` and ``np.linalg.pinv`` can be faster on hermitian inputs\n--------------------------------------------------------------------------\nThese functions now accept a ``hermitian`` argument, matching the one added\nto ``np.linalg.matrix_rank`` in 1.14.0.\n\ndivmod operation is now supported for two ``timedelta64`` operands\n------------------------------------------------------------------\nThe divmod operator now handles two ``np.timedelta64`` operands, with\ntype signature mm-&gt;qm.\n\n``np.fromfile`` now takes an ``offset`` argument\n------------------------------------------------\nThis function now takes an ``offset`` keyword argument for binary files,\nwhich specifics the offset (in bytes) from the file&#39;s current position.\nDefaults to 0.\n\nNew mode &quot;empty&quot; for ``np.pad``\n-------------------------------\nThis mode pads an array to a desired shape without initializing the new\nentries.\n\n``np.empty_like`` and related functions now accept a ``shape`` argument\n-----------------------------------------------------------------------\n``np.empty_like``, ``np.full_like``, ``np.ones_like`` and ``np.zeros_like`` now\naccept a ``shape`` keyword argument, which can be used to create a new array\nas the prototype, overriding its shape as well. This is particularly useful\nwhen combined with the ``__array_function__`` protocol, allowing the creation\nof new arbitrary-shape arrays from NumPy-like libraries when such an array\nis used as the prototype.\n\nFloating point scalars implement ``as_integer_ratio`` to match the builtin float\n--------------------------------------------------------------------------------\nThis returns a (numerator, denominator) pair, which can be used to construct a\n`fractions.Fraction`.\n\nStructured ``dtype`` objects can be indexed with multiple fields names\n----------------------------------------------------------------------\n``arr.dtype[[&#39;a&#39;, &#39;b&#39;]]`` now returns a dtype that is equivalent to\n``arr[[&#39;a&#39;, &#39;b&#39;]].dtype``, for consistency with\n``arr.dtype[&#39;a&#39;] == arr[&#39;a&#39;].dtype``.\n\nLike the dtype of structured arrays indexed with a list of fields, this dtype\nhas the same ``itemsize`` as the original, but only keeps a subset of the fields.\n\nThis means that ``arr[[&#39;a&#39;, &#39;b&#39;]]`` and ``arr.view(arr.dtype[[&#39;a&#39;, &#39;b&#39;]])`` are\nequivalent.\n\n``.npy`` files support unicode field names\n------------------------------------------\nA new format version of 3.0 has been introduced, which enables structured types\nwith non-latin1 field names. This is used automatically when needed.\n\n`numpy.packbits` and `numpy.unpackbits` accept an ``order`` keyword\n-------------------------------------------------------------------\nThe ``order`` keyword defaults to ``big``, and will order the **bits**\naccordingly. For ``&#39;big&#39;`` 3 will become ``[0, 0, 0, 0, 0, 0, 1, 1]``, and\n``[1, 1, 0, 0, 0, 0, 0, 0]`` for ``little``\n\n\nImprovements\n============\n\nArray comparison assertions include maximum differences\n-------------------------------------------------------\nError messages from array comparison tests such as\n`np.testing.assert_allclose` now include &quot;max absolute difference&quot; and\n&quot;max relative difference,&quot; in addition to the previous &quot;mismatch&quot; percentage.\nThis information makes it easier to update absolute and relative error\ntolerances.\n\nReplacement of the fftpack based FFT module by the pocketfft library\n--------------------------------------------------------------------\nBoth implementations have the same ancestor (Fortran77 FFTPACK by Paul N.\nSwarztrauber), but pocketfft contains additional modifications which improve\nboth accuracy and performance in some circumstances. For FFT lengths containing\nlarge prime factors, pocketfft uses Bluestein&#39;s algorithm, which maintains\n``O(N log N)`` run time complexity instead of deteriorating towards ``O(N*N)``\nfor prime lengths. Also, accuracy for real valued FFTs with near prime lengths\nhas improved and is on par with complex valued FFTs.\n\nFurther improvements to ``ctypes`` support in `numpy.ctypeslib`\n---------------------------------------------------------------\nA new `numpy.ctypeslib.as_ctypes_type` function has been added, which can be\nused to converts a ``dtype`` into a best-guess ``ctypes`` type. Thanks to this\nnew function, `numpy.ctypeslib.as_ctypes` now supports a much wider range of\narray types, including structures, booleans, and integers of non-native\nendianness.\n\n`numpy.errstate` is now also a function decorator\n-------------------------------------------------\nCurrently, if you have a function like::\n\n    def foo():\n        pass\n\nand you want to wrap the whole thing in ``errstate``, you have to rewrite it\nlike so::\n\n    def foo():\n        with np.errstate(...):\n            pass\n\nbut with this change, you can do::\n\n    np.errstate(...)\n    def foo():\n        pass\n\nthereby saving a level of indentation\n\n`numpy.exp` and `numpy.log` speed up for float32 implementation\n---------------------------------------------------------------\nfloat32 implementation of numpy.exp and numpy.log now benefit from AVX2/AVX512\ninstruction set which are detected during runtime. numpy.exp has a max ulp\nerror of 2.52 and numpy.log has a max ulp error or 3.83.\n\nImprove performance of `numpy.pad`\n----------------------------------\nThe performance of the function has been improved for most cases by filling in\na preallocated array with the desired padded shape instead of using\nconcatenation.\n\n`numpy.interp` handles infinities more robustly\n-----------------------------------------------\nIn some cases where ``np.interp`` would previously return ``np.nan``, it now\nreturns an appropriate infinity.\n\nPathlib support for ``np.fromfile``, ``ndarray.tofile`` and ``ndarray.dump``\n----------------------------------------------------------------------------\n``np.fromfile``, ``np.ndarray.tofile`` and ``np.ndarray.dump`` now support\nthe `pathlib.Path` type for the ``file``/``fid`` parameter.\n\nSpecialized ``np.isnan``, ``np.isinf``, and ``np.isfinite`` ufuncs for bool and int types\n-----------------------------------------------------------------------------------------\nThe boolean and integer types are incapable of storing ``np.nan`` and\n``np.inf`` values, which allows us to provide specialized ufuncs that are up to\n250x faster than the current approach.\n\n``np.isfinite`` supports ``datetime64`` and ``timedelta64`` types\n-----------------------------------------------------------------\nPreviously, `np.isfinite` used to raise a ``TypeError`` on being used on these\ntwo types.\n\nNew keywords added to ``np.nan_to_num``\n---------------------------------------\n``np.nan_to_num`` now accepts keywords ``nan``, ``posinf`` and ``neginf``\nallowing the user to define the value to replace the ``nan``, positive and\nnegative ``np.inf`` values respectively.\n\nMemoryErrors caused by allocated overly large arrays are more descriptive\n-------------------------------------------------------------------------\nOften the cause of a MemoryError is incorrect broadcasting, which results in a\nvery large and incorrect shape. The message of the error now includes this\nshape to help diagnose the cause of failure.\n\n`floor`, `ceil`, and `trunc` now respect builtin magic methods\n--------------------------------------------------------------\nThese ufuncs now call the ``__floor__``, ``__ceil__``, and ``__trunc__``\nmethods when called on object arrays, making them compatible with\n`decimal.Decimal` and `fractions.Fraction` objects.\n\n``quantile`` now works on ``fraction.Fraction`` and ``decimal.Decimal`` objects\n-------------------------------------------------------------------------------\nIn general, this handles object arrays more gracefully, and avoids floating-\npoint operations if exact arithmetic types are used.\n\nSupport of object arrays in ``np.matmul``\n-----------------------------------------\nIt is now possible to use ``np.matmul`` (or the ` operator) with object arrays.\nFor instance, it is now possible to do::\n\n    from fractions import Fraction\n    a = np.array([[Fraction(1, 2), Fraction(1, 3)], [Fraction(1, 3), Fraction(1, 2)]])\n    b = a  a\n\n\nChanges\n=======\n\n``median`` and ``percentile`` family of functions no longer warn about ``nan``\n------------------------------------------------------------------------------\n`numpy.median`, `numpy.percentile`, and `numpy.quantile` used to emit a\n``RuntimeWarning`` when encountering an `numpy.nan`. Since they return the\n``nan`` value, the warning is redundant and has been removed.\n\n``timedelta64 % 0`` behavior adjusted to return ``NaT``\n-------------------------------------------------------\nThe modulus operation with two ``np.timedelta64`` operands now returns\n``NaT`` in the case of division by zero, rather than returning zero\n\nNumPy functions now always support overrides with ``__array_function__``\n------------------------------------------------------------------------\nNumPy now always checks the ``__array_function__`` method to implement overrides\nof NumPy functions on non-NumPy arrays, as described in `NEP 18`_. The feature\nwas available for testing with NumPy 1.16 if appropriate environment variables\nare set, but is now always enabled.\n\n.. _`NEP 18` : http://www.numpy.org/neps/nep-0018-array-function-protocol.html\n\n`numpy.lib.recfunctions.structured_to_unstructured` does not squeeze single-field views\n---------------------------------------------------------------------------------------\nPreviously ``structured_to_unstructured(arr[[&#39;a&#39;]])`` would produce a squeezed\nresult inconsistent with ``structured_to_unstructured(arr[[&#39;a&#39;, b&#39;]])``. This\nwas accidental. The old behavior can be retained with\n``structured_to_unstructured(arr[[&#39;a&#39;]]).squeeze(axis=-1)`` or far more simply,\n``arr[&#39;a&#39;]``.\n\n``clip`` now uses a ufunc under the hood\n----------------------------------------\nThis means that registering clip functions for custom dtypes in C via\n``descr-&gt;f-&gt;fastclip`` is deprecated - they should use the ufunc registration\nmechanism instead, attaching to the ``np.core.umath.clip`` ufunc.\n\nIt also means that ``clip`` accepts ``where`` and ``casting`` arguments,\nand can be override with ``__array_ufunc__``.\n\nA consequence of this change is that some behaviors of the old ``clip`` have\nbeen deprecated:\n\n* Passing ``nan`` to mean &quot;do not clip&quot; as one or both bounds. This didn&#39;t work\n  in all cases anyway, and can be better handled by passing infinities of the\n  appropriate sign.\n* Using &quot;unsafe&quot; casting by default when an ``out`` argument is passed. Using\n  ``casting=&quot;unsafe&quot;`` explicitly will silence this warning.\n\nAdditionally, there are some corner cases with behavior changes:\n\n* Padding ``max &lt; min`` has changed to be more consistent across dtypes, but\n  should not be relied upon.\n* Scalar ``min`` and ``max`` take part in promotion rules like they do in all\n  other ufuncs.\n\n``__array_interface__`` offset now works as documented\n------------------------------------------------------\nThe interface may use an ``offset`` value that was mistakenly ignored.\n\nPickle protocol in ``np.savez`` set to 3 for ``force zip64`` flag\n-----------------------------------------------------------------\n``np.savez`` was not using the ``force_zip64`` flag, which limited the size of\nthe archive to 2GB. But using the flag requires us to use pickle protocol 3 to\nwrite ``object`` arrays. The protocol used was bumped to 3, meaning the archive\nwill be unreadable by Python2.\n\nStructured arrays indexed with non-existent fields raise ``KeyError`` not ``ValueError``\n----------------------------------------------------------------------------------------\n``arr[&#39;bad_field&#39;]`` on a structured type raises ``KeyError``, for consistency\nwith ``dict[&#39;bad_field&#39;]``.\n\n.. _`NEP 18` : http://www.numpy.org/neps/nep-0018-array-function-protocol.html\n\n\n=========================\n   ```\n   \n  \n</details>\n\n\n \n\n<details>\n  <summary>Links</summary>\n  \n  - PyPI: https://pypi.org/project/numpy\n  - Changelog: https://pyup.io/changelogs/numpy/\n  - Homepage: https://www.numpy.org\n</details>\n\n\n\n\n\n### Update [dask[array]](https://pypi.org/project/dask) from **1.2.2** to **2.2.0**.\n\n\n*The bot wasn't able to find a changelog for this release. [Got an idea?](https://github.com/pyupio/changelogs/issues/new)*\n\n<details>\n  <summary>Links</summary>\n  \n  - PyPI: https://pypi.org/project/dask\n  - Repo: https://github.com/dask/dask/\n</details>\n\n\n\n\n\n### Update [matplotlib](https://pypi.org/project/matplotlib) from **3.1.0** to **3.1.1**.\n\n\n<details>\n  <summary>Changelog</summary>\n  \n  \n   ### 3.1.1\n   ```\n   The first bug-fix release of the 3.1 series\n\n  * Locator.nonsingular return order API change\n\nLots of backports of various bug fixes.\n   ```\n   \n  \n</details>\n\n\n \n\n<details>\n  <summary>Links</summary>\n  \n  - PyPI: https://pypi.org/project/matplotlib\n  - Changelog: https://pyup.io/changelogs/matplotlib/\n  - Homepage: https://matplotlib.org\n</details>\n\n\n\n\n\n### Update [pandas](https://pypi.org/project/pandas) from **0.24.2** to **0.25.0**.\n\n\n*The bot wasn't able to find a changelog for this release. [Got an idea?](https://github.com/pyupio/changelogs/issues/new)*\n\n<details>\n  <summary>Links</summary>\n  \n  - PyPI: https://pypi.org/project/pandas\n  - Homepage: http://pandas.pydata.org\n</details>\n\n\n\n\n\n### Update [scikit-learn](https://pypi.org/project/scikit-learn) from **0.21.2** to **0.21.3**.\n\n\n<details>\n  <summary>Changelog</summary>\n  \n  \n   ### 0.21.3\n   ```\n   A bug fix and documentation release, fixing regressions and other issues released in version 0.21. See change log at https://scikit-learn.org/0.21/whats_new/v0.21.html\n   ```\n   \n  \n</details>\n\n\n \n\n<details>\n  <summary>Links</summary>\n  \n  - PyPI: https://pypi.org/project/scikit-learn\n  - Changelog: https://pyup.io/changelogs/scikit-learn/\n  - Homepage: http://scikit-learn.org\n</details>\n\n\n\n\n\n","created_at":"2019-08-01T15:28:12Z","updated_at":"2019-08-01T15:28:12Z","closed_at":null,"merged_at":null,"merge_commit_sha":null,"assignee":null,"assignees":[],"requested_reviewers":[],"requested_teams":[],"labels":[],"milestone":null,"commits_url":"https://api.github.com/repos/cggh/scikit-allel/pulls/282/commits","review_comments_url":"https://api.github.com/repos/cggh/scikit-allel/pulls/282/comments","review_comment_url":"https://api.github.com/repos/cggh/scikit-allel/pulls/comments{/number}","comments_url":"https://api.github.com/repos/cggh/scikit-allel/issues/282/comments","statuses_url":"https://api.github.com/repos/cggh/scikit-allel/statuses/22f763ae24344e6323722f19310d872dfb8b1de2","head":{"label":"cggh:pyup-scheduled-update-2019-08-01","ref":"pyup-scheduled-update-2019-08-01","sha":"22f763ae24344e6323722f19310d872dfb8b1de2","user":{"login":"cggh","id":7804180,"node_id":"MDEyOk9yZ2FuaXphdGlvbjc4MDQxODA=","avatar_url":"https://avatars3.githubusercontent.com/u/7804180?v=4","gravatar_id":"","url":"https://api.github.com/users/cggh","html_url":"https://github.com/cggh","followers_url":"https://api.github.com/users/cggh/followers","following_url":"https://api.github.com/users/cggh/following{/other_user}","gists_url":"https://api.github.com/users/cggh/gists{/gist_id}","starred_url":"https://api.github.com/users/cggh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cggh/subscriptions","organizations_url":"https://api.github.com/users/cggh/orgs","repos_url":"https://api.github.com/users/cggh/repos","events_url":"https://api.github.com/users/cggh/events{/privacy}","received_events_url":"https://api.github.com/users/cggh/received_events","type":"Organization","site_admin":false},"repo":{"id":29883079,"node_id":"MDEwOlJlcG9zaXRvcnkyOTg4MzA3OQ==","name":"scikit-allel","full_name":"cggh/scikit-allel","private":false,"owner":{"login":"cggh","id":7804180,"node_id":"MDEyOk9yZ2FuaXphdGlvbjc4MDQxODA=","avatar_url":"https://avatars3.githubusercontent.com/u/7804180?v=4","gravatar_id":"","url":"https://api.github.com/users/cggh","html_url":"https://github.com/cggh","followers_url":"https://api.github.com/users/cggh/followers","following_url":"https://api.github.com/users/cggh/following{/other_user}","gists_url":"https://api.github.com/users/cggh/gists{/gist_id}","starred_url":"https://api.github.com/users/cggh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cggh/subscriptions","organizations_url":"https://api.github.com/users/cggh/orgs","repos_url":"https://api.github.com/users/cggh/repos","events_url":"https://api.github.com/users/cggh/events{/privacy}","received_events_url":"https://api.github.com/users/cggh/received_events","type":"Organization","site_admin":false},"html_url":"https://github.com/cggh/scikit-allel","description":"A Python package for exploring and analysing genetic variation data","fork":false,"url":"https://api.github.com/repos/cggh/scikit-allel","forks_url":"https://api.github.com/repos/cggh/scikit-allel/forks","keys_url":"https://api.github.com/repos/cggh/scikit-allel/keys{/key_id}","collaborators_url":"https://api.github.com/repos/cggh/scikit-allel/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/cggh/scikit-allel/teams","hooks_url":"https://api.github.com/repos/cggh/scikit-allel/hooks","issue_events_url":"https://api.github.com/repos/cggh/scikit-allel/issues/events{/number}","events_url":"https://api.github.com/repos/cggh/scikit-allel/events","assignees_url":"https://api.github.com/repos/cggh/scikit-allel/assignees{/user}","branches_url":"https://api.github.com/repos/cggh/scikit-allel/branches{/branch}","tags_url":"https://api.github.com/repos/cggh/scikit-allel/tags","blobs_url":"https://api.github.com/repos/cggh/scikit-allel/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/cggh/scikit-allel/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/cggh/scikit-allel/git/refs{/sha}","trees_url":"https://api.github.com/repos/cggh/scikit-allel/git/trees{/sha}","statuses_url":"https://api.github.com/repos/cggh/scikit-allel/statuses/{sha}","languages_url":"https://api.github.com/repos/cggh/scikit-allel/languages","stargazers_url":"https://api.github.com/repos/cggh/scikit-allel/stargazers","contributors_url":"https://api.github.com/repos/cggh/scikit-allel/contributors","subscribers_url":"https://api.github.com/repos/cggh/scikit-allel/subscribers","subscription_url":"https://api.github.com/repos/cggh/scikit-allel/subscription","commits_url":"https://api.github.com/repos/cggh/scikit-allel/commits{/sha}","git_commits_url":"https://api.github.com/repos/cggh/scikit-allel/git/commits{/sha}","comments_url":"https://api.github.com/repos/cggh/scikit-allel/comments{/number}","issue_comment_url":"https://api.github.com/repos/cggh/scikit-allel/issues/comments{/number}","contents_url":"https://api.github.com/repos/cggh/scikit-allel/contents/{+path}","compare_url":"https://api.github.com/repos/cggh/scikit-allel/compare/{base}...{head}","merges_url":"https://api.github.com/repos/cggh/scikit-allel/merges","archive_url":"https://api.github.com/repos/cggh/scikit-allel/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/cggh/scikit-allel/downloads","issues_url":"https://api.github.com/repos/cggh/scikit-allel/issues{/number}","pulls_url":"https://api.github.com/repos/cggh/scikit-allel/pulls{/number}","milestones_url":"https://api.github.com/repos/cggh/scikit-allel/milestones{/number}","notifications_url":"https://api.github.com/repos/cggh/scikit-allel/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/cggh/scikit-allel/labels{/name}","releases_url":"https://api.github.com/repos/cggh/scikit-allel/releases{/id}","deployments_url":"https://api.github.com/repos/cggh/scikit-allel/deployments","created_at":"2015-01-26T21:42:44Z","updated_at":"2019-07-31T04:51:30Z","pushed_at":"2019-08-01T15:28:11Z","git_url":"git://github.com/cggh/scikit-allel.git","ssh_url":"git@github.com:cggh/scikit-allel.git","clone_url":"https://github.com/cggh/scikit-allel.git","svn_url":"https://github.com/cggh/scikit-allel","homepage":"","size":37835,"stargazers_count":127,"watchers_count":127,"language":"Jupyter Notebook","has_issues":true,"has_projects":true,"has_downloads":true,"has_wiki":true,"has_pages":false,"forks_count":24,"mirror_url":null,"archived":false,"disabled":false,"open_issues_count":61,"license":{"key":"mit","name":"MIT License","spdx_id":"MIT","url":"https://api.github.com/licenses/mit","node_id":"MDc6TGljZW5zZTEz"},"forks":24,"open_issues":61,"watchers":127,"default_branch":"master"}},"base":{"label":"cggh:master","ref":"master","sha":"0fa09dd3cce23e781e2e7ef6e8870ee86cb6d62d","user":{"login":"cggh","id":7804180,"node_id":"MDEyOk9yZ2FuaXphdGlvbjc4MDQxODA=","avatar_url":"https://avatars3.githubusercontent.com/u/7804180?v=4","gravatar_id":"","url":"https://api.github.com/users/cggh","html_url":"https://github.com/cggh","followers_url":"https://api.github.com/users/cggh/followers","following_url":"https://api.github.com/users/cggh/following{/other_user}","gists_url":"https://api.github.com/users/cggh/gists{/gist_id}","starred_url":"https://api.github.com/users/cggh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cggh/subscriptions","organizations_url":"https://api.github.com/users/cggh/orgs","repos_url":"https://api.github.com/users/cggh/repos","events_url":"https://api.github.com/users/cggh/events{/privacy}","received_events_url":"https://api.github.com/users/cggh/received_events","type":"Organization","site_admin":false},"repo":{"id":29883079,"node_id":"MDEwOlJlcG9zaXRvcnkyOTg4MzA3OQ==","name":"scikit-allel","full_name":"cggh/scikit-allel","private":false,"owner":{"login":"cggh","id":7804180,"node_id":"MDEyOk9yZ2FuaXphdGlvbjc4MDQxODA=","avatar_url":"https://avatars3.githubusercontent.com/u/7804180?v=4","gravatar_id":"","url":"https://api.github.com/users/cggh","html_url":"https://github.com/cggh","followers_url":"https://api.github.com/users/cggh/followers","following_url":"https://api.github.com/users/cggh/following{/other_user}","gists_url":"https://api.github.com/users/cggh/gists{/gist_id}","starred_url":"https://api.github.com/users/cggh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cggh/subscriptions","organizations_url":"https://api.github.com/users/cggh/orgs","repos_url":"https://api.github.com/users/cggh/repos","events_url":"https://api.github.com/users/cggh/events{/privacy}","received_events_url":"https://api.github.com/users/cggh/received_events","type":"Organization","site_admin":false},"html_url":"https://github.com/cggh/scikit-allel","description":"A Python package for exploring and analysing genetic variation data","fork":false,"url":"https://api.github.com/repos/cggh/scikit-allel","forks_url":"https://api.github.com/repos/cggh/scikit-allel/forks","keys_url":"https://api.github.com/repos/cggh/scikit-allel/keys{/key_id}","collaborators_url":"https://api.github.com/repos/cggh/scikit-allel/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/cggh/scikit-allel/teams","hooks_url":"https://api.github.com/repos/cggh/scikit-allel/hooks","issue_events_url":"https://api.github.com/repos/cggh/scikit-allel/issues/events{/number}","events_url":"https://api.github.com/repos/cggh/scikit-allel/events","assignees_url":"https://api.github.com/repos/cggh/scikit-allel/assignees{/user}","branches_url":"https://api.github.com/repos/cggh/scikit-allel/branches{/branch}","tags_url":"https://api.github.com/repos/cggh/scikit-allel/tags","blobs_url":"https://api.github.com/repos/cggh/scikit-allel/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/cggh/scikit-allel/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/cggh/scikit-allel/git/refs{/sha}","trees_url":"https://api.github.com/repos/cggh/scikit-allel/git/trees{/sha}","statuses_url":"https://api.github.com/repos/cggh/scikit-allel/statuses/{sha}","languages_url":"https://api.github.com/repos/cggh/scikit-allel/languages","stargazers_url":"https://api.github.com/repos/cggh/scikit-allel/stargazers","contributors_url":"https://api.github.com/repos/cggh/scikit-allel/contributors","subscribers_url":"https://api.github.com/repos/cggh/scikit-allel/subscribers","subscription_url":"https://api.github.com/repos/cggh/scikit-allel/subscription","commits_url":"https://api.github.com/repos/cggh/scikit-allel/commits{/sha}","git_commits_url":"https://api.github.com/repos/cggh/scikit-allel/git/commits{/sha}","comments_url":"https://api.github.com/repos/cggh/scikit-allel/comments{/number}","issue_comment_url":"https://api.github.com/repos/cggh/scikit-allel/issues/comments{/number}","contents_url":"https://api.github.com/repos/cggh/scikit-allel/contents/{+path}","compare_url":"https://api.github.com/repos/cggh/scikit-allel/compare/{base}...{head}","merges_url":"https://api.github.com/repos/cggh/scikit-allel/merges","archive_url":"https://api.github.com/repos/cggh/scikit-allel/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/cggh/scikit-allel/downloads","issues_url":"https://api.github.com/repos/cggh/scikit-allel/issues{/number}","pulls_url":"https://api.github.com/repos/cggh/scikit-allel/pulls{/number}","milestones_url":"https://api.github.com/repos/cggh/scikit-allel/milestones{/number}","notifications_url":"https://api.github.com/repos/cggh/scikit-allel/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/cggh/scikit-allel/labels{/name}","releases_url":"https://api.github.com/repos/cggh/scikit-allel/releases{/id}","deployments_url":"https://api.github.com/repos/cggh/scikit-allel/deployments","created_at":"2015-01-26T21:42:44Z","updated_at":"2019-07-31T04:51:30Z","pushed_at":"2019-08-01T15:28:11Z","git_url":"git://github.com/cggh/scikit-allel.git","ssh_url":"git@github.com:cggh/scikit-allel.git","clone_url":"https://github.com/cggh/scikit-allel.git","svn_url":"https://github.com/cggh/scikit-allel","homepage":"","size":37835,"stargazers_count":127,"watchers_count":127,"language":"Jupyter Notebook","has_issues":true,"has_projects":true,"has_downloads":true,"has_wiki":true,"has_pages":false,"forks_count":24,"mirror_url":null,"archived":false,"disabled":false,"open_issues_count":61,"license":{"key":"mit","name":"MIT License","spdx_id":"MIT","url":"https://api.github.com/licenses/mit","node_id":"MDc6TGljZW5zZTEz"},"forks":24,"open_issues":61,"watchers":127,"default_branch":"master"}},"_links":{"self":{"href":"https://api.github.com/repos/cggh/scikit-allel/pulls/282"},"html":{"href":"https://github.com/cggh/scikit-allel/pull/282"},"issue":{"href":"https://api.github.com/repos/cggh/scikit-allel/issues/282"},"comments":{"href":"https://api.github.com/repos/cggh/scikit-allel/issues/282/comments"},"review_comments":{"href":"https://api.github.com/repos/cggh/scikit-allel/pulls/282/comments"},"review_comment":{"href":"https://api.github.com/repos/cggh/scikit-allel/pulls/comments{/number}"},"commits":{"href":"https://api.github.com/repos/cggh/scikit-allel/pulls/282/commits"},"statuses":{"href":"https://api.github.com/repos/cggh/scikit-allel/statuses/22f763ae24344e6323722f19310d872dfb8b1de2"}},"author_association":"NONE","merged":false,"mergeable":null,"rebaseable":null,"mergeable_state":"unknown","merged_by":null,"comments":0,"review_comments":0,"maintainer_can_modify":false,"commits":6,"additions":6,"deletions":6,"changed_files":1}}
{"actor":{"display_login":"pyup-bot"}}