[Python 3.10] Remove APIs deprecated long enough

[methane]

BPO	41165
Nosy	@tiran, @methane, @hroncok, @hugovk, @miss-islington, @tirkarthi
PRs	bpo-41165: Remove PyEval_AcquireLock and PyEval_ReleaseLock #21273 bpo-41165: unittest: Remove assertion aliases #21276 bpo-41165: Deprecate PyEval_ReleaseLock() #21309 [3.9] bpo-41165: Deprecate PyEval_ReleaseLock() (GH-21309) #21345

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2021-06-09.10:11:22.815>
created_at = <Date 2020-06-30.04:53:16.495>
labels = ['easy', 'library', '3.10']
title = '[Python 3.10] Remove APIs deprecated long enough'
updated_at = <Date 2021-08-18.09:27:28.253>
user = 'https://github.com/methane'

bugs.python.org fields:

activity = <Date 2021-08-18.09:27:28.253>
actor = 'hugovk'
assignee = 'none'
closed = True
closed_date = <Date 2021-06-09.10:11:22.815>
closer = 'methane'
components = ['Library (Lib)']
creation = <Date 2020-06-30.04:53:16.495>
creator = 'methane'
dependencies = []
files = []
hgrepos = []
issue_num = 41165
keywords = ['patch', 'easy']
message_count = 14.0
messages = ['372653', '372654', '372804', '372814', '372821', '372823', '372828', '372830', '372901', '372913', '373034', '373066', '373067', '399825']
nosy_count = 6.0
nosy_names = ['christian.heimes', 'methane', 'hroncok', 'hugovk', 'miss-islington', 'xtreak']
pr_nums = ['21273', '21276', '21309', '21345']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue41165'
versions = ['Python 3.10']

[methane]

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

[methane]

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

[methane]

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

[tiran]

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.

[methane]

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.

[methane]

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.

[methane]

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.

[tirkarthi]

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

[methane]

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.

[methane]

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

[tirkarthi]

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

[methane]

New changeset 9ce8132 by Inada Naoki in branch 'master':
bpo-41165: Deprecate PyEval_ReleaseLock() (GH-21309)
9ce8132

[miss-islington]

New changeset 1ce59f0 by Miss Islington (bot) in branch '3.9':
bpo-41165: Deprecate PyEval_ReleaseLock() (GH-21309)
1ce59f0

[hugovk]

## 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:

pypa/setuptools#1878
pytest-dev/pytest#5546
pytest-dev/pytest#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"?