Most changes to Pythonrequire a NEWS entry.

Please add it using theblurb_it web app or theblurb command-line tool.

There is a problem: raiseDeprecationWarning will break many lib tests, since they use the (type, val, tb) exception representation.

Eg:

We could report aSilentDeprecationWarning, then gradually fix the tests, and then later change it into aDeprecationWarning.

Whoops, there's no such thing. Maybe it once existed, but it doesn't now, so ignore this option. :-)

One nit. Too bad about the failing tests, let's brainstorm what to do about them:

Let's estimate the problem size, by finding with regexthrow\(.*,.*,.*\)

There are 51 results in 12 files.

• 3 file is underLib
• 1 is inLib/lib2to3/fixes
• The rest are tests.
• 51 results in 12 files.txt

• We could just fix them, replacing .throw(A, B, C) with .throw(B).
• We could first fix the tests, in batches, and then land this PR.

I prefer fixing them in this PR, for the fix need to be verified by raising an error. Otherwise the batch fix might miss something.

• However, the batch plan would be clearer, in Issue and PR history.

We could add filterwarnings() calls to the offending tests (I don't recall how to do that but there are probable plenty of examples).

filterwarnings() call might be a safety valve, if I am not quite confident about how some tests work.

Okay, make sure you considerthis.

Also, some of the hits may be tests for this very feature, those should not be "fixed" but you may have to add awith self.warns() on those.

Most changes to Pythonrequire a NEWS entry.

Please add it using theblurb_it web app or theblurb command-line tool.

I run./python -m test，and fixed clear cases, changed them to.throw(val) form.

However, there are still someDeprecationWarnings need to be handle. As@iritkatriel said incomment of 96348, some of the tests need to stay.

1. Generator's doc test

I think we should filter theDeprecationWarning here, for it's testing exactly the deprecated API.

2. Libunittest.case

It happens here:

The output is like:

/../cpython/Lib/unittest/case.py:237: DeprecationWarning: the (type, val, tb) exception representationis deprecated, and may be removed in a future version of Python.  callable_obj(*args, **kwargs)

I am not sure whatcallable_obj does here, and maybe filtering this warning requires a change in standard library of python?

/../cpython/Lib/unittest/case.py:237: DeprecationWarning: the (type, val, tb) exception representationis deprecated, and may be removed in a future version of Python.  callable_obj(*args, **kwargs)

I am not sure whatcallable_obj does here, and maybe filtering this warning requires a change in standard library of python?

Look at the code in Lib/unittest/case.py. This is part of the assertRaises mechanism. The callable_obj and the args passed to it are defined by the test, so this should be dealt with in the particular test and not here in the test framework.

I am not sure whatcallable_obj does here, and maybe filtering this warning requires a change in standard library of python?

Look at the code in Lib/unittest/case.py. This is part of the assertRaises mechanism. The callable_obj and the args passed to it are defined by the test, so this should be dealt with in the particular test and not here in the test framework.

The test is this one. It's testing the types of the triplet, so we need to keep it and suppress the deprecation warning.

    def test_future_iter_throw(self):        fut = self._new_future(loop=self.loop)        fi = iter(fut)        self.assertRaises(TypeError, fi.throw,                           Exception, Exception("elephant"), 32)        self.assertRaises(TypeError, fi.throw,                          Exception("elephant"), Exception("elephant"))        self.assertRaises(TypeError, fi.throw, list)

Okay, handled the remaining warnings.

Tested with those scripts:

./python -mtest -j16> test.log; cat test.log| grep"DeprecationWarning: the (type, val, tb) exception representation is deprecated"# Come out with nothing./python -Werror -m unittest -v test.test_asyncio.test_futures.PyFutureTests.test_future_iter_throw test.test_generators# OK

Besides, should I squash all commits into one, when all the reviews are done?

Don’t squash please! It makes review harder. We will squash upon merge.

🤖 New build scheduled with the buildbot fleet by@iritkatriel for commit8b701d6 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

It seems that my tests exposed some problem - there are 3 versions of futures, and only one of them is emitting the deprecation warning?

Looking at the code, if futures._CFuture is fixed (made to raise the deprecation warning) then that will fix CSubFuture as well.

So I think we need one more deprecation warning from FutureIter_throw in
Modules/_asynciomodule.c.

It seems that my tests exposed some problem - there are 3 versions of futures, and only one of them is emitting the deprecation warning?

The warning is added.

But I still feel a little dizzy about it - How do you know that we should add a test in test_futures.py? Is python future implemented by coroutine object or async generator?

• My guess: According to the doc, so test_future.py is testing the high-level interface of coroutine object, from that we know that we should add a test oniter(future).throw.

Theconcurrent.futures module provides a high-level interface for asynchronously executing callables.
concurrent.futures — Launching parallel tasks

@kumaraditya303 How does it look now? (I'm a little dizzy by now as well).

You only need to add deprecation warning in_CFuture since it is implemented in C. The pure Python versions uses regular generators so they will automatically emit warning since warning is added togenerator.throw.