I don't think we need to remove them all at onece. But we can remove some of them for code health.

c-api/module.rst

.. c:function:: const char* PyModule_GetFilename(PyObject *module)
   .. deprecated:: 3.2

c-api/init.rst

.. c:function:: void PyEval_AcquireLock()
   .. deprecated:: 3.2

.. c:function:: void PyEval_ReleaseLock()
   .. deprecated:: 3.2

unittest:

   .. deprecated:: 3.1
         The fail* aliases listed in the second column have been deprecated.
   .. deprecated:: 3.2
         The assert* aliases listed in the third column have been deprecated.
   .. deprecated:: 3.2
         ``assertRegexpMatches`` and ``assertRaisesRegexp`` have been renamed to
         :meth:`.assertRegex` and :meth:`.assertRaisesRegex`.

urllib.request:

.. class:: URLopener(proxies=None, **x509)
   .. deprecated:: 3.3
.. class:: FancyURLopener(...)
   .. deprecated:: 3.3

turtle:
.. function:: settiltangle(angle)
   .. deprecated:: 3.1

imp:
.. function:: get_suffixes()
.. function:: find_module(name[, path])
.. function:: load_module(name, file, pathname, description)
.. data:: PY_SOURCE
.. data:: PY_COMPILED
.. data:: C_EXTENSION
.. data:: PKG_DIRECTORY
.. data:: C_BUILTIN
.. data:: PY_FROZEN

configparser:
   .. method:: readfp(fp, filename=None)
      .. deprecated:: 3.2

email.errors:

* :class:`MalformedHeaderDefect` -- A header was found that was missing a colon,
  or was otherwise malformed.

  .. deprecated:: 3.3

pkgutil:
.. class:: ImpImporter(dirname=None)
   .. deprecated:: 3.3
.. class:: ImpLoader(fullname, file, filename, etc)
   .. deprecated:: 3.3

zipfile:
.. exception:: BadZipfile

   Alias of :exc:`BadZipFile`, for compatibility with older Python versions.

   .. deprecated:: 3.2

inspect:
.. function:: getargspec(func)
   .. deprecated:: 3.0

asyncore:
      .. deprecated:: 3.2

importlib:
.. class:: Finder
   .. deprecated:: 3.3

    .. method:: path_mtime(path)
        .. deprecated:: 3.3

PyModule_GetFilename, PyEval_AcquireLock, PyEval_ReleaseLock.
Are they part of stable ABI?

Unittest aliases are deprecated in #9424.
Can we remove them in Python 3.10?

I'm all in favor to remove deprecated things, but please set a tangible deadline first. A lot of these functions have been deprecated for like a decade. Users tend to forget about deprecations or assume that removal was never going to happen. For example the removal of xml.etree.cElementTree broke a bunch of stuff although it had been deprecated since 3.0.

At a bare minimum you should list removed features in the 3.9 changelog and porting guide as "will be removed in 3.10". I would even argue to add deprecation warnings to the code in 3.9 (with permission from the RM). If the RM is against deprecation warnings, then it might be good idea to postpone removal to 3.11.

I don't propose adding DeprecationWarning in 3.9 in this issue.
I don't propose removing functions that don't emit DeprecationWarning.

My first message is just a starting point. I don't propose to remove them all.

For the record, I noticed DeprecationWarning is not shown by unittest.runner by default.

For example, https://travis-ci.org/github/necaris/python3-openid/jobs/703119609

So deprecated aliases should be not removed in 3.10.

I found most of deprecated items in my first comment are aliving by difficult reasons.

I grepped top 4000 packages and found some candidates to deprecate.


## turtle

* settiltangle is not used anywhere.
* tiltangle is also deprecated by docstring, but not in the document.
* Both methods don't emit DeprecationWarning.

TODO(easy): Update the document and emit DeprecationWarning


## email.errors

MalformedHeaderDefect is not used anywhere in top4000 packages.

But it is simple alias, and DeprecationWarning is not emit.

TODO(easy): Emit DeprecationWarning using module __getattr__.


## importlib

abc.SourceLoader.path_mtime is not used anywhere.

TODO: Remove path_mtime from the ABC and raise DeprecationWarning if path_mtime is defined in subclass in path_stats.

---

importlib should be checked by experts.  I keep TODO(easy) for new contributors.

> For the record, I noticed DeprecationWarning is not shown by unittest.runner by default.

There is an open issue for this but I think it's enabled by default https://bugs.python.org/issue39892

$ cat /tmp/test_bar.py
import unittest
import warnings


class TestFoo(unittest.TestCase):

    def test_foo(self):
        self.assertEquals(1, 1)


if __name__ == "__main__":
    unittest.main()

$ python3.8 -m unittest test_bar
/private/tmp/test_bar.py:8: DeprecationWarning: Please use assertEqual instead.
  self.assertEquals(1, 1)
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

Hmm.  You are right. The warnings are shown by default.

On the other hand, some project uses custom `setup.py test` command. It hides the DeprecationWarning.

https://github.com/warner/python-ed25519/blob/master/setup.py
https://github.com/warner/python-ed25519/blob/master/src/ed25519/test_ed25519.py#L42

How about emitting FutureWarning instead of DeprecationWarning?

DeprecationWarning is hidden to avoid end users see noisy warnings.
But test is for developers, not end users.

As we discussed in ML, PyEval_ReleaseLock is still used and removing may be not simple. Keep it as-is until Python 4.0.

Adding Miro since Fedora will be testing Python 3.10 and deprecated API removals here might potentially affect libraries like Python 3.9 testing.

New changeset 9ce8132e1f2339cfe116dfd4795574182c2245b4 by Inada Naoki in branch 'master':
bpo-41165: Deprecate PyEval_ReleaseLock() (GH-21309)
https://github.com/python/cpython/commit/9ce8132e1f2339cfe116dfd4795574182c2245b4

New changeset 1ce59f0421d9550762977454bda22db750aa20aa by Miss Islington (bot) in branch '3.9':
bpo-41165: Deprecate PyEval_ReleaseLock() (GH-21309)
https://github.com/python/cpython/commit/1ce59f0421d9550762977454bda22db750aa20aa

## unittest

What's needed to move forward with removing the deprecated aliases?

A deprecation warning is shown for `python3 -m unittest test_bar` and `python3 test_bar.py` (tested Python 3.6-3.10).

No deprecation warning is shown for `python setup.py test`, however, both setuptools and pytest have deprecated/discouraged `python setup.py test`:

https://github.com/pypa/setuptools/pull/1878
https://github.com/pytest-dev/pytest/pull/5546
https://github.com/pytest-dev/pytest/issues/5534

Docs already mention they are deprecated:

https://docs.python.org/3/library/unittest.html#deprecated-aliases

> At a bare minimum you should list removed features in the 3.9 changelog and porting guide as "will be removed in 3.10". I would even argue to add deprecation warnings to the code in 3.9 (with permission from the RM). If the RM is against deprecation warnings, then it might be good idea to postpone removal to 3.11.

So at this stage (3.10 in RC), do we need to list them in the 3.11 changelog and porting guide as "will be removed in 3.12"?