[Numpy-discussion] ANN: SciPy 1.5.2

[Tyler Reddy]

Hi all,

On behalf of the SciPy development team I'm pleased to announce
the release of SciPy 1.5.2, 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.5.2

One of a few ways to install this release with pip:

pip install scipy==1.5.2

==
SciPy 1.5.2 Release Notes
==

SciPy 1.5.2 is a bug-fix release with no new features
compared to 1.5.1.

Authors
==

* Peter Bell
* Tobias Biester +
* Evgeni Burovski
* Thomas A Caswell
* Ralf Gommers
* Sturla Molden
* Andrew Nelson
* ofirr +
* Sambit Panda
* Ilhan Polat
* Tyler Reddy
* Atsushi Sakai
* Pauli Virtanen

A total of 13 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
This list of names is automatically generated, and may not be fully
complete.


Issues closed for 1.5.2
--

* `#3847 `__: Crash of
interpolate.splprep(task=-1)
* `#7395 `__: splprep segfaults
if fixed knots are specified
* `#10761 `__:
scipy.signal.convolve2d produces incorrect values for large arrays
* `#11971 `__: DOC: search in
devdocs returns wrong link
* `#12155 `__: BUG: Fix
permutation of distance matrices in scipy.stats.multiscale_graphcorr
* `#12203 `__: Unable to
install on PyPy 7.3.1 (Python 3.6.9)
* `#12316 `__: negative
scipy.spatial.distance.correlation
* `#12422 `__: BUG: slsqp:
ValueError: failed to initialize intent(inout) array...
* `#12428 `__:
stats.truncnorm.rvs() never returns a scalar in 1.5
* `#12441 `__: eigvalsh
inconsistent eigvals= subset_by_index=
* `#12445 `__: DOC:
scipy.linalg.eigh
* `#12449 `__: Warnings are
not filtered in csr_matrix.sum()
* `#12469 `__: SciPy 1.9
exception in LSQSphereBivariateSpline
* `#12487 `__: BUG: optimize:
incorrect result from approx_fprime
* `#12493 `__: CI: GitHub
Actions for maintenance branches
* `#12533 `__: eigh gives
incorrect results
* `#12579 `__: BLD, MAINT:
distutils issues in wheels repo

Pull requests for 1.5.2
---

* `#12156 `__: BUG: Fix
permutation of distance matrices in scipy.stats.multiscale_graphcorr
* `#12238 `__: BUG: Use 64-bit
indexing in convolve2d to avoid overflow
* `#12256 `__: BLD: Build lsap
as a single extension instead of extension +...
* `#12320 `__: BUG: spatial:
avoid returning negative correlation distance
* `#12383 `__: ENH: Make
cKDTree.tree more efficient
* `#12392 `__: DOC: update
scipy-sphinx-theme
* `#12430 `__: BUG: truncnorm
and geninvgauss never return scalars from rvs
* `#12437 `__: BUG: optimize:
cast bounds to floats in new_bounds_to_old/old_bounds_to_new
* `#12442 `__: MAINT:linalg: Fix
for input args of eigvalsh
* `#12461 `__: MAINT: sparse:
write matrix/asmatrix wrappers without warning...
* `#12478 `__: BUG: fix
array_like input defects and add tests for all functions...
* `#12488 `__: BUG: fix
approx_derivative step size. Closes #12487
* `#12500 `__: CI: actions
branch trigger fix
* `#12501 `__: CI: actions
branch trigger fix
* `#12504 `__: BUG: cKDTreeNode
use after free
* `#12529 `__: MAINT: allow
graceful docs re-upload
* `#12538 `__: BUG:linalg: eigh
type parameter handling corrected
* `#12560 `__: MAINT:
truncnorm.rvs compatibility for \`Generator\`
* `#12562 `__: redo gh-12188:
fix segfaults in splprep with fixed knots
* `#12586 

Re: [Numpy-discussion] Why does fancy indexing work like this?

[Aaron Meurer]

> After writing this, I realized that I actually remember the *opposite*
> discussion occurring before.  I think in some of the equality
> deprecations, we actually raise the new error due to an internal
> try/except clause.  And there was a complaint that its confusing that a
> non-deprecation-warning is raised when the error will only happen with
> DeprecationWarnings being set to error.
>
> - Sebastian

I noticed that warnings.catch_warnings does the right thing with
warnings that are raised alongside an exception (although it is a bit
clunky to use).

Aaron Meurer
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Why does fancy indexing work like this?

[Sebastian Berg]

On Thu, 2020-07-23 at 10:18 -0500, Sebastian Berg wrote:
> On Wed, 2020-07-22 at 17:35 -0600, Aaron Meurer wrote:
> > > About your warnings, do you have a nice way to do that?  The
> > > mechanism
> > > for warnings does not really give a good way to catch that a
> > > warning
> > > was raised and then turn it into an error.  Unless someone
> > > contributes
> > > a slick way to do it, I am not sure the complexity pays off.
> > 
> > I don't really know how flags and options and such work in NumPy,
> > but
> > I would imagine something like
> > 
> > if flags['post-deprecation'] = True: # Either a single flag for all
> > deprecations or a per-deprecation flag
> > raise IndexError(...)
> > else:
> > warnings.warn(...)
> > 
> 
> We have never done global flags for these things much in NumPy, I
> don't
> know of precedence in other packages, possibly aside future imports,
> but I am not even sure they have been used in this way.
> 
> > I don't know if the fact that the code that does this is in C
> > complicates things.
> > 
> > In other words, something that works kind of like __future__ flags
> > for
> > upgrading the behavior to post-deprecation.
> > 
> > > IIRC, I added the note about raising the warning, because in this
> > > particular case the deprecation warning (turned into an error)
> > > happens
> > > to be chained due to implementation details.  (so you do see the
> > > "original" error printed out).
> > 
> > Yes, it's nice that you can see it. But for my use case, I want to
> > be
> > able to "except IndexError". Basically, for ndindex, I test against
> > NumPy to make sure the semantics are identical, and that includes
> > making sure identical exceptions are raised. I also want to make it
> > so
> > that the ndindex semantics always follow post-deprecation behavior
> > for
> > any NumPy deprecations, since that leads to a cleaner API. But that
> > means that my test code has to do fancy shenanigans to catch these
> > deprecation warnings and treat them like the right errors.
> > 
> > But even as a general principle, I think for any deprecation
> > warning,
> > users should be able to update their code in such a way that the
> > current version doesn't give the warning and also it will continue
> > to
> 
> For FutureWarnings, I will always try very hard to give an option to
> opt-in to new behaviour or old behaviour – ideally with code
> compatible
> also with earlier NumPy versions.
> 
> Here, for a DeprecationWarning that has obviously no "alternative", I
> cannot think of any precedence in any other package or Python itself
> doing such a dance.  And it is extremely fringe (you only need it
> because you are testing another package against numpy behaviour!).
> 
> So I am happy to merge it if its proposed (maybe its easier for you
> to
> add this to NumPy then work around it in your tests), but I am
> honestly
> concerned that proposing this as a general principle is far more
> churn
> then worth the trouble.  At least unless there is some consensus (and
> probably precendence in the scientific python ecosystem or python
> itself).
> 

After writing this, I realized that I actually remember the *opposite*
discussion occurring before.  I think in some of the equality
deprecations, we actually raise the new error due to an internal
try/except clause.  And there was a complaint that its confusing that a
non-deprecation-warning is raised when the error will only happen with
DeprecationWarnings being set to error.

- Sebastian


> Cheers,
> 
> Sebastian
> 
> 
> > work and be idiomatic for future versions. For simple deprecations
> > where you remove a function x(), this is often as simple as telling
> > people to replace x() with y(). But these deprecations aren't so
> > simple, because the indexing itself is valid and will stay valid,
> > it's
> > just the behavior that will change. If there's no way to do this,
> > then
> > a deprecation warning serves little purpose because users who see
> > the
> > warning won't be able to do anything about it until things actually
> > change. There would be little difference from just changing things
> > outright. For the list as tuple indexing thing, you can already
> > kind
> > of do this by making sure your fancy indices are always arrays. For
> > the out of bounds one, it's a little harder. I guess for most
> > use-cases, you aren't actually checking for IndexErrors, and the
> > thing
> > that will become an error usually indicates a bug in user code, so
> > maybe it isn't a huge deal (I admit my use-cases aren't typical).
> > 
> > Aaron Meurer
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> > 
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion



signature.asc
Description: This is a digitally sig

Re: [Numpy-discussion] Why does fancy indexing work like this?

[Sebastian Berg]

On Wed, 2020-07-22 at 17:35 -0600, Aaron Meurer wrote:
> > About your warnings, do you have a nice way to do that?  The
> > mechanism
> > for warnings does not really give a good way to catch that a
> > warning
> > was raised and then turn it into an error.  Unless someone
> > contributes
> > a slick way to do it, I am not sure the complexity pays off.
> 
> I don't really know how flags and options and such work in NumPy, but
> I would imagine something like
> 
> if flags['post-deprecation'] = True: # Either a single flag for all
> deprecations or a per-deprecation flag
> raise IndexError(...)
> else:
> warnings.warn(...)
> 

We have never done global flags for these things much in NumPy, I don't
know of precedence in other packages, possibly aside future imports,
but I am not even sure they have been used in this way.

> I don't know if the fact that the code that does this is in C
> complicates things.
> 
> In other words, something that works kind of like __future__ flags
> for
> upgrading the behavior to post-deprecation.
> 
> > IIRC, I added the note about raising the warning, because in this
> > particular case the deprecation warning (turned into an error)
> > happens
> > to be chained due to implementation details.  (so you do see the
> > "original" error printed out).
> 
> Yes, it's nice that you can see it. But for my use case, I want to be
> able to "except IndexError". Basically, for ndindex, I test against
> NumPy to make sure the semantics are identical, and that includes
> making sure identical exceptions are raised. I also want to make it
> so
> that the ndindex semantics always follow post-deprecation behavior
> for
> any NumPy deprecations, since that leads to a cleaner API. But that
> means that my test code has to do fancy shenanigans to catch these
> deprecation warnings and treat them like the right errors.
> 
> But even as a general principle, I think for any deprecation warning,
> users should be able to update their code in such a way that the
> current version doesn't give the warning and also it will continue to

For FutureWarnings, I will always try very hard to give an option to
opt-in to new behaviour or old behaviour – ideally with code compatible
also with earlier NumPy versions.

Here, for a DeprecationWarning that has obviously no "alternative", I
cannot think of any precedence in any other package or Python itself
doing such a dance.  And it is extremely fringe (you only need it
because you are testing another package against numpy behaviour!).

So I am happy to merge it if its proposed (maybe its easier for you to
add this to NumPy then work around it in your tests), but I am honestly
concerned that proposing this as a general principle is far more churn
then worth the trouble.  At least unless there is some consensus (and
probably precendence in the scientific python ecosystem or python
itself).

Cheers,

Sebastian


> work and be idiomatic for future versions. For simple deprecations
> where you remove a function x(), this is often as simple as telling
> people to replace x() with y(). But these deprecations aren't so
> simple, because the indexing itself is valid and will stay valid,
> it's
> just the behavior that will change. If there's no way to do this,
> then
> a deprecation warning serves little purpose because users who see the
> warning won't be able to do anything about it until things actually
> change. There would be little difference from just changing things
> outright. For the list as tuple indexing thing, you can already kind
> of do this by making sure your fancy indices are always arrays. For
> the out of bounds one, it's a little harder. I guess for most
> use-cases, you aren't actually checking for IndexErrors, and the
> thing
> that will become an error usually indicates a bug in user code, so
> maybe it isn't a huge deal (I admit my use-cases aren't typical).
> 
> Aaron Meurer
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
> 



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion