Ineffective deprecation warnings

[mkoeppe]

As observed in #14270 with 9.4.beta4, some of our deprecation warnings are currently not issued.

This happens through an interaction of several flaws.

• fixing invalid escape sequences in various places #26132 (merged in Sage 8.4) broke the filterwarnings regex in sage.all that is supposed to make "sure to keep OUR deprecation warnings"
• counting the stacklevel may depend on whether Cython functions are involved

This ticket fixes these two issues. As a result, the following deprecation warning is again issued:

sage: var('y')
y
sage: (x+y)(1, 2)
<ipython-input-2-63751830fa4e>:1: DeprecationWarning: Substitution using function-call syntax and unnamed arguments is deprecated and will be removed from a future release of Sage; you can use named arguments instead, like EXPR(x=..., y=...)
See http://trac.sagemath.org/5930 for details.
  (x+y)(Integer(1), Integer(2))
3

In addition, some of the regexes in filterwarnings in sage.all are too broad, such as matching on module='.*ast' (added in #30184). We remove all leading .* for module patterns -- they are only needed when some deprecation warnings are introduced by vendored versions of some modules -- for example, pip vendors packaging as pip._vendor.packaging. This can be checked by find local/lib/python*/ -name "_vendor" | xargs ls

CC: @fchapoton @tscrim @jhpalmieri @vbraun

Component: refactoring

Author: Matthias Koeppe

Branch/Commit: 69a81ca

Reviewer: John Palmieri

Issue created by migration from https://trac.sagemath.org/ticket/32139

[mkoeppe]

Description changed:

--- 
+++ 
@@ -1,4 +1,4 @@
-As observed in #14270 with 9.4.beta4, some of our = deprecation warnings are currently not issued.
+As observed in #14270 with 9.4.beta4, some of our deprecation warnings are currently not issued.
 
 This happens through an interaction of several flaws.
 - #26132 broke the `filterwarnings` regex in `sage.all` that is supposed to make "sure to keep OUR deprecation warnings"

[mkoeppe]

Branch: u/mkoeppe/ineffective_deprecation_warnings

[mkoeppe]

Description changed:

--- 
+++ 
@@ -4,6 +4,18 @@
 - #26132 broke the `filterwarnings` regex in `sage.all` that is supposed to make "sure to keep OUR deprecation warnings"
 - counting the `stacklevel` may depend on whether Cython functions are involved
 
+This ticket fixes these two issues. As a result, the following deprecation warning is again issued:
+
+```
+sage: var('y')
+y
+sage: (x+y)(1, 2)
+<ipython-input-2-63751830fa4e>:1: DeprecationWarning: Substitution using function-call syntax and unnamed arguments is deprecated and will be removed from a future release of Sage; you can use named arguments instead, like EXPR(x=..., y=...)
+See http://trac.sagemath.org/5930 for details.
+  (x+y)(Integer(1), Integer(2))
+3
+```
+
 In addition, some of the regexes in `filterwarnings` in `sage.all` are too broad, such as matching on `module='.*ast'` 
 
 

[mkoeppe]

Commit: 4191337

[mkoeppe]

New commits:

4191337

src/sage/all.py: Repair the filterwarnings regexp that ensures sagelib warnings are not ignored

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

6492b8c

src/sage/symbolic/ring.pyx: Pass the correct stacklevel to deprecatio()

[sagetrac-git]

Changed commit from 4191337 to 6492b8c

[mkoeppe]

Description changed:

--- 
+++ 
@@ -16,6 +16,7 @@
 3
 ```
 
-In addition, some of the regexes in `filterwarnings` in `sage.all` are too broad, such as matching on `module='.*ast'` 
+In addition, some of the regexes in `filterwarnings` in `sage.all` are too broad, such as matching on `module='.*ast'` (added in #30184)
 
 
+

[mkoeppe]

Description changed:

--- 
+++ 
@@ -16,7 +16,9 @@
 3
 ```
 
-In addition, some of the regexes in `filterwarnings` in `sage.all` are too broad, such as matching on `module='.*ast'` (added in #30184)
+In addition, some of the regexes in `filterwarnings` in `sage.all` are too broad, such as matching on `module='.*ast'` (added in #30184). We remove all leading `.*` -- they are only be needed when some deprecation warnings are introduced by vendored versions of some modules -- for example, `pip` vendors `packaging` as `pip._vendor.packaging`. This can be checked by `find local/lib/python*/ -name "_vendor" | xargs ls`
 
 
 
+
+

[mkoeppe]

Description changed:

--- 
+++ 
@@ -1,7 +1,7 @@
 As observed in #14270 with 9.4.beta4, some of our deprecation warnings are currently not issued.
 
 This happens through an interaction of several flaws.
-- #26132 broke the `filterwarnings` regex in `sage.all` that is supposed to make "sure to keep OUR deprecation warnings"
+- #26132 (merged in Sage 8.4) broke the `filterwarnings` regex in `sage.all` that is supposed to make "sure to keep OUR deprecation warnings"
 - counting the `stacklevel` may depend on whether Cython functions are involved
 
 This ticket fixes these two issues. As a result, the following deprecation warning is again issued:

[sagetrac-git]

Changed commit from 6492b8c to 04fdda6

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

04fdda6

sage.all: In filterwarnings, remove leading '.*' from module regexes, use regex that matches vendored 'packaging'

[mkoeppe]

Author: Matthias Koeppe

[jhpalmieri]

comment:10

It's not as though we're vigilant about removing old deprecated code, but do we need to somehow add a grace period for code connected to the reappearing deprecation warnings? If someone decides in the near future to remove the code deprecated in #5930, is that okay?

[mkoeppe]

comment:11

Replying to @jhpalmieri:

If someone decides in the near future to remove the code deprecated in #5930

I just did in the revived #14270.