[issue39892] Enable DeprecationWarnings by default when not explicit in unittest.main()

[Gregory P. Smith]

Gregory P. Smith  added the comment:

my bad :)

--
resolution:  -> not a bug
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39892] Enable DeprecationWarnings by default when not explicit in unittest.main()

[STINNER Victor]

Change by STINNER Victor :


--
nosy:  -vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39892] Enable DeprecationWarnings by default when not explicit in unittest.main()

[Nick Coghlan]

Nick Coghlan  added the comment:

Issue 10535 says they should already be on by default in unittest.

I seem to recall checking that was still true when implementing the default 
warning filter changes in 3.7.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39892] Enable DeprecationWarnings by default when not explicit in unittest.main()

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39892] Enable DeprecationWarnings by default when not explicit in unittest.main()

[Gregory P. Smith]

New submission from Gregory P. Smith :

Recurring theme: The stdlib has the issue of DeprecationWarning being added to 
APIs we are changing or removing a few versions in the future yet we perceive 
that many people never actually bother to try checking their code for 
deprecation warnings.  Only raising issues with a documented, warned, planned 
in advance API change when it actually happens.

Could we reduce the chances of this by enabling DeprecationWarnings by default 
for processes started via unittest.main() and other common unittest 
entrypoints?  (other test frameworks like pytest should also consider this if 
they don't already; do we have any existing external implementations of this 
for inspiration?)

One issue with this is that some important warnings are at _parse_ time or 
_import_ time.  But we can deal with import time ones if we are able to have 
the unittest entrypoint re-exec the process with the same args but with 
warnings enabled.  (and _could_ surface parse time ones if we're willing to 
accept slower process startup by disabling use of pycs; i wouldn't go that far)

Related work: https://www.python.org/dev/peps/pep-0565/

has this idea already been discussed?  I don't remember and haven't searched 
backwards...

--
components: Library (Lib), Tests
messages: 363620
nosy: gregory.p.smith, ncoghlan, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Enable DeprecationWarnings by default when not explicit in 
unittest.main()
type: enhancement
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com