GeezerVison

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

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

Eg:

We could report a SilentDeprecationWarning, then gradually fix the tests, and then later change it into a DeprecationWarning.

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 regex throw\(.*,.*,.*\)

There are 51 results in 12 files.

• 3 file is under Lib
• 1 is in Lib/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 consider this.

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

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

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

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

1. Generator's doc test

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

2. Lib unittest.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 what callable_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 what callable_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 what callable_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 -m test -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 commit 8b701d6 🤖

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 on iter(future).throw.

The concurrent.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 to generator.throw.