Open jakkdl opened 2 months ago
I was concerned for a bit but backwards compaibility is trivial for this. The only times TrioDeprecationWarning
will happen is for current deprecations that should disappear in max 2 releases (well, except strict_exception_groups
... not sure what to do for that).
So we just, for every new deprecation, start raising DeprecationWarning
instead (simple kwarg on warn_deprecated
?). The only case I think that might disrupt is if someone specifically wants to ignore all deprecations from Trio and decided that ignoring TrioDeprecationWarning
generally is good. But I'm fine breaking their workflow, if that person exists.
We could just do the equivalent of
import warnings
# this is in src/trio/_deprecate
MyTrioDeprecationWarning = DeprecationWarning
# and this is what people are currently doing, suppressing TrioDeprecationWarning
with warnings.catch_warnings():
warnings.filterwarnings('ignore', category=MyTrioDeprecationWarning)
# It still silences DeprecationWarning
warnings.warn(DeprecationWarning("hello"))
And the only warning suppression that would break is if people are filtering on FutureWarning
. But maybe people are doing that, since specifying custom warning categories on the command line is non-trivial (maybe not even posssible? idk I couldn't quickly figure it out at least)
$ python -W ignore::FutureWarning foo.py
$ python -W ignore::TrioDeprecationWarning foo.py
Invalid -W option ignored: unknown warning category: 'TrioDeprecationWarning'
/home/h/Git/trio/deprecate_deprecationwarning/foo.py:10: TrioDeprecationWarning: trio.run(..., strict_exception_groups=False) is deprecated since Trio 0.24.1; use the default value of True and rewrite exception handlers to handle ExceptionGroups instead (https://github.com/python-trio/trio/issues/2929)
trio.run(foo, strict_exception_groups=False)
We should maybe ask in gitter & search repos on github.
The current deprecationwarnings, other than strict_exception_groups
are to_thread.run_sync(cancellable=...)
#2841 and open_tcp_listeners(backlog=math.inf)
#2842.
I partly resolved this in #2989, by adding a use_triodeprecationwarning
parameter that defaults to False
; and updating current deprecations to pass True
. So only thing remaining is if we want to do anything to current deprecations.
I was thinking about whether to use
DeprecationWarning
orTrioDeprecationWarning
in #2989, when I decided to actually figure out what the difference is and whyTrioDeprecationWarning
is a thing. It lines up with https://bugs.python.org/issue24294, which was resolved with https://peps.python.org/pep-0565/ and released in python3.7Since we don't support 3.6 and earlier, the original reason for its existence is gone, so we at the very least should make it inherit from
DeprecationWarning
instead ofFutureWarning
and update the docstring. Or we go even further and removeTrioDeprecationWarning
entirely (with an intermediate period of making it a pure alias ofDeprecationWarning
but emitting aDeprecationWarning
). Having helper methods linking to issues and stuff is still helpful though, and after recent discussions in Gitter we maybe also want a parameter for how long we're planning to keep the deprecated thing around before it gets removed.