Question about deprecation warnings: when do they appear in doctests vs. real life?

[John H Palmieri]

Here is a doctest from sage/rings/integer.pyx:

        sage: Integer('012')

        doctest:...: DeprecationWarning: use 0o as octal prefix instead of 0
        If you do not want this number to be interpreted as octal, remove the leading zeros.
        See http://trac.sagemath.org/17413 for details.
        10

But if I run the command Integer('012')from the command line (in a newly started Sage session) or the Jupyter notebook, no deprecation warning is printed. Same if I just evaluate 012. Is this a bug? It seems to defeat the purpose of the deprecation warning, which is to actually warn people that a feature is going away, not just to provide extra characters in docstrings and the reference manual.

--

John

[David Roe]

The reason that the warning isn't printed is that the stacklevel is set to 4 by default in order to tell the user where the Integer('012') is occurring.  When you type '012' directly into the command line, the stack isn't deep enough and no warning is printed.  You do see a warning if you write a function that uses it:

sage: def hello():
....:     Integer('012')
....:    
sage: hello()
/home/sage/sage-8.8/src/bin/sage-ipython:1: DeprecationWarning: use 0o as octal prefix instead of 0

If you do not want this number to be interpreted as octal, remove the leading zeros.
See http://trac.sagemath.org/17413 for details.

  #!/usr/bin/env sage-python23

I think the idea is that if a user's typing interactively then they don't need a deprecation warning (since the behavior currently works).  It's more important to show a user a warning if they have the deprecated behavior in a function they've written.

David

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/6569111a-90ac-436f-8ecb-2976a9b32ab3%40googlegroups.com.

[John H Palmieri]

Okay, that makes sense. I thought I had seen deprecation warnings from basic commands issued at the "sage:" prompt, but I must be misremembering.

  John

To unsubscribe from this group and stop receiving emails from it, send an email to sage-...@googlegroups.com.

[Simon King]

Hi David,

On 2019-10-19, David Roe <roed...@gmail.com> wrote:
> I think the idea is that if a user's typing interactively then they don't
> need a deprecation warning (since the behavior currently works). It's more
> important to show a user a warning if they have the deprecated behavior in
> a function they've written.

I don't like that idea. If they write code, I suppose many people
test their code in an interactive session while writing it. So, it would
be fair to show them during the interactive session that the code
they're about to write is deprecated.

Best regards,
Simon

[David Roe]

I don't mind changing the behavior, I was just trying to explain why it's currently as is.  If we do make a change, we'll probably have to detect an interactive session as a special case so that we can keep the current behavior when called from a function.

David

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/qoh6qq%2439ev%241%40blaine.gmane.org.

[Vincent Delecroix]

See

https://trac.sagemath.org/ticket/28500

[Vincent Delecroix]

Le 19/10/2019 à 13:19, David Roe a écrit :
> I think the idea is that if a user's typing interactively then they don't
> need a deprecation warning (since the behavior currently works). It's more
> important to show a user a warning if they have the deprecated behavior in
> a function they've written.

I don't agree with this behavior at all. A user typically wants to know
whether her commands are future-proof. Typical situation: I want to show
a colleague how to do this and that in sage cell. Damn I have a
different version on my computer! The commands that run smoothly in my
console fail in the sage cell.

And note that many people write Sage scripts with no function at all
(e.g. in a Sage notebook, or in a .sage file).

[Vincent Delecroix]

Finally, whatever choice of behavior is made, it should be consistent
between Python and Cython. See

https://trac.sagemath.org/ticket/28500

[Nils Bruin]

On Saturday, October 19, 2019 at 1:20:15 PM UTC-7, David Roe wrote:

I think the idea is that if a user's typing interactively then they don't need a deprecation warning (since the behavior currently works).  It's more important to show a user a warning if they have the deprecated behavior in a function they've written.

 

I'm pretty sure that's not the reason. As you can see from https://trac.sagemath.org/ticket/28500, the stack depth is tuned so that the warning references the stack frame of the *call site* of the function raises the deprecation warning. That makes sense, because that's where the change should be made if you want to avoid calling a deprecated function. That works just fine from the interpreter top level, because there is a stack frame corresponding to top level.

The problem arises when the deprecation warning is raised in a cython function, since cython doesn't create python stack frames. With one less frame on the stack, the warning ends up referencing the level *above* the call site, which is there in the doctest framework, but not at top-level in the interpreter. In the doctest it means there's a nonsensical callsite referenced (but this is not checked by the doctests); in the interpreter it means the warning gets swallowed because a a failure in finding a stack frame [I think that behaviour is a bug in Python's warning machinery. It's a silent failure to issue a warning in a case where some warning is almost certainly desired].

The obvious solution is to use a different "deprecation" in cython code: one that uses a stack depth of one less. This is quite easy to implement by providing a "deprecation_cython" as well and use something like "from sage.misc.superseded import deprecation_cython as deprecation" in cython files instead of the usual. Making this change is quite straightforward (it can probably be done by a script if you really want to) and is completely uncontroversial. It is a bit of work, though, and it will be touching a lot of files.

[Nils Bruin]

On Sunday, October 20, 2019 at 2:00:49 PM UTC-7, Nils Bruin wrote:

[I think that behaviour is a bug in Python's warning machinery. It's a silent failure to issue a warning in a case where some warning is almost certainly desired].

Correcting myself on this one. Nothing is wrong in python itself. The swallowing happens because IPython filters warnings that seem the emanate from itself. We end up referencing a stack frame above the "top level", which is from an internal IPython routine. I ended up discovering that when trying to devise a meaningful doctest for the fix that is now available for review on https://trac.sagemath.org/ticket/28500. The ticket is marked "blocker", which is perhaps a little excessive for the type of issue. The fix is very easy, though.