I'm creating this issue and marking it as a deferred blocker to make sure we don't forget to check this (adding tests) before the release.

Check this message from Serhiy regarding heap typed concerns:

https://bugs.python.org/msg391598

Serhiy's comment for reference:

Static type with tp_new = NULL does not have public constructor, but heap type inherits constructor from base class. As result, it allows to create instances without proper initialization, that can lead to crash. It was fixed for few standard heap types in issue23815, then reintroduced, then fixed again in issue42694. But it should be checked for every type without constructor.

From Objects/typeobject.c:

        /* The condition below could use some explanation.
           It appears that tp_new is not inherited for static types
           whose base class is 'object'; this seems to be a precaution
           so that old extension types don't suddenly become
           callable (object.__new__ wouldn't insure the invariants
           that the extension type's own factory function ensures).
           Heap types, of course, are under our control, so they do
           inherit tp_new; static extension types that specify some
           other built-in type as the default also
           inherit object.__new__. */
        if (base != &PyBaseObject_Type ||
            (type->tp_flags & Py_TPFLAGS_HEAPTYPE)) {
            if (type->tp_new == NULL)
                type->tp_new = base->tp_new;
        }

The explaining comment was added in f884b749103bad0724e2e4878cd5fe49a41bd7df.

The code itself is much older. It was originally added in 6d6c1a35e08b95a83dbe47dbd9e6474daff00354, then
weaked in c11e192d416e2970e6a06cf06d4cf788f322c6ea and strengthen in 29687cd2112c540a8a4d31cf3b191cf10db08412.

All types except static types which are direct descendants of object inherit tp_new from a base class.

We need to check which static types had tp_new = NULL before they were converted to heap types and set it to NULL manually after type creation.

> We need to check which static types had tp_new = NULL before they were converted to heap types

I did a quick git grep. Results pasted into the list over at https://discuss.python.org/t/list-of-built-in-types-converted-to-heap-types/8403.

It is incomplete. For example arrayiterator did have tp_new = NULL (in other words, PyArrayIter_Type.tp_new was not set to non-NULL value).

In 3.9:

>>> import array
>>> type(iter(array.array('I')))()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'arrayiterator' instances

In 3.10:

>>> import array
>>> type(iter(array.array('I')))()
<array.arrayiterator object at 0x7f02f88db5c0>

> It is incomplete.

Yes, I know. I'm working on completing it manually. Some of the static structs were only partially initialised (most stop at tp_members). The rest of the struct (including tp_new) would then be initialised to zero.

Thank you for your work Erlend.

Serhiy, do you think this should be a release blocker for the beta?

> Thank you for your work Erlend.

Anytime! I've updated the list now. There may still be errors, but I think it's pretty accurate now.

Here's a plaintext version:

- 0b858cdd5d2021-01-04 Modules/cjkcodecs/multibytecodec.c
    - _multibytecodec.MultibyteCodec

- c8a87addb1 2021-01-04 Modules/pyexpat.c
    - pyexpat.xmlparser

- 75bf107c62 2021-01-02 Modules/arraymodule.c
    - array.arrayiterator

- dd39123970 2020-12-29 Modules/_functoolsmodule.c
    - functools.KeyWrapper
    - functools._lru_list_elem

- 6104013838 2020-12-18 Modules/_threadmodule.c
    - _thread.lock
    - _thread._localdummy

- a6109ef68d 2020-11-20 Modules/_sre.c
    - re.Pattern
    - re.Match
    - _sre.SRE_Scanner

- c8c4200b65 2020-10-26 Modules/unicodedata.c
    - unicodedata.UCD

- 256e54acdb 2020-10-01 Modules/_sqlite
    - sqlite3.Connection
    - sqlite3.Cursor

- 9031bd4fa4 2020-10-01 Modules/_sqlite
    - sqlite3.Row
    - sqlite3.Statement

- cb6db8b6ae 2020-09-27 Modules/_sqlite
    - sqlite3.Node
    - sqlite3.Cache

- 52a2df135c 2020-09-08 Modules/sha256module.c
    - _sha256.sha224
    - _sha256.sha256

- 2aabc3200b 2020-09-06 Modules/md5module.c Modules/sha1module.c Modules/sha512module.c
    - _md5.md5
    - _sha1.sha1
    - _sha512.sha384
    - _sha512.sha512

- e087f7cd43 2020-08-13 Modules/_winapi.c
    - winapi__overlapped.Overlapped

- c4862e333a 2020-06-17 Modules/_gdbmmodule.c
    - g_dbm.dbm

- bf69a8f99f 2020-06-16 Modules/_dbmmodule.c
    - _dbm.dbm

- 33f15a16d4 2019-11-05 Modules/posixmodule.c
    - posix.DirEntry
    - posix.ScandirIterator

- df69e75edc 2019-09-25 Modules/_hashopenssl.c
    - _hashlib.HASH

- f919054e53 2019-09-14 Modules/selectmodule.c
    - select.devpoll
    - select.kevent
    - select.poll

- 04f0bbfbed 2019-09-10 Modules/zlibmodule.c
    - zlib.Compress
    - zlib.Decompress

- 4f384af067 2012-10-14 Modules/_tkinter.c
    - _tkinter.Tcl_Obj
    - _tkinter.tktimertoken
    - _tkinter.tkapp

- bc07cb883e 2012-06-14 Modules/_curses_panel.c
    - _curses_panel.panel

Is there any way we can fix this in Objects/typeobject.c, or do we actually have to patch every single type manually?

> Is there any way we can fix this in Objects/typeobject.c, or do we actually have to patch every single type manually?

That would be probably a bad idea since typeobject.c is supposed to be generic. We would be inverting the responsibility concerns to the base.

I afraid that changing the corresponding code in Objects/typeobject.c will break existing user code. For now, it is safer to patch every single type manually. Later we can design a general solution.

I am marking this as a release blocker, giving that this is probably going to involve a big change.

Is it worth it adding tests for this? I'm thinking a generic version of msg391910 (maybe Lib/test/test_uninitialised_heap_types.py) coupled with a dataset.

I have had this workaround in _hashopenssl.c for a while. Can I get rid of the function with "{Py_tp_new, NULL}" or is there a more generic way to accomplish the same goal?

/* {Py_tp_new, NULL} doesn't block __new__ */
static PyObject *
_disabled_new(PyTypeObject *type, PyObject *args, PyObject *kwargs)
{
    PyErr_Format(PyExc_TypeError,
        "cannot create '%.100s' instances", _PyType_Name(type));
    return NULL;
}

test_uninitialised_heap_types.py will need to import unrelited modules (some of which can be platform depending). And more modules will be added as more types be converted. I think it is better to add tests for different modules in corresponding module test files. They are pretty trivial, for example:

    def test_new_tcl_obj(self):
        self.assertRaises(TypeError, _tkinter.Tcl_Obj)

    @requires_curses_func('panel')
    def test_new_curses_panel(self):
        w = curses.newwin(10, 10)
        panel = curses.panel.new_panel(w)
        self.assertRaises(TypeError, type(panel))

You're right, that would become messy. Complementing existing test suites is a better approach.

Christian:
> Can I get rid of the function with "{Py_tp_new, NULL}" [...]

Unfortunately not. The workaround in 993e88cf08994f7c1e0f9f62fda4ed32634ee2ad does the trick though.

Pablo, I've made a patch for most of these (I've left out Christian's modules). I've only added a couple of tests for now. Do you want all in one PR?

$ git diff main --stat  
 Lib/test/test_array.py             | 4 ++++
 Lib/test/test_unicodedata.py       | 4 ++++
 Modules/_dbmmodule.c               | 1 +
 Modules/_functoolsmodule.c         | 2 ++
 Modules/_gdbmmodule.c              | 1 +
 Modules/_sre.c                     | 5 +++++
 Modules/_threadmodule.c            | 2 ++
 Modules/_winapi.c                  | 1 +
 Modules/arraymodule.c              | 1 +
 Modules/cjkcodecs/multibytecodec.c | 1 +
 Modules/posixmodule.c              | 2 ++
 Modules/pyexpat.c                  | 1 +
 Modules/unicodedata.c              | 1 +
 Modules/zlibmodule.c               | 2 ++
 14 files changed, 28 insertions(+)


I don't know why I included the sqlite3 and select types in msg391924; they are not affected by this issue. Somebody should double check that everything's covered.

> Pablo, I've made a patch for most of these (I've left out Christian's modules). I've only added a couple of tests for now. Do you want all in one PR?

Yes, please. The second most important part here is also adding regression tests so this doesn't happen. These tests should also be added when new types are converted in the future.

> These tests should also be added when new types are converted in the future.

We should have a checklist for static to heap type conversion. I'm pretty sure I've seen something like that in one of Victor's blogs. A new section in the Dev Guide, maybe?

Alternative approach:

Add _PyType_DisabledNew to Include/cpython, and add {Py_tp_new, _PyType_DisabledNew} slot to affected types. Diff attached.

See GH discussion:
- https://github.com/python/cpython/pull/25653#issuecomment-827383246
- https://github.com/python/cpython/pull/25653#issuecomment-827390034

LGTM

Alternatively we can make PyType_FromSpec() setting tp_new to NULL if there is explicit {Py_tp_new, NULL} in slots.

> Alternatively we can make PyType_FromSpec() setting tp_new to NULL if there is explicit {Py_tp_new, NULL} in slots.

Yes. It's not as explicit (and self-documenting) as _PyType_DisabledNew, though. But it avoids expanding the C API.

For that to work, you'd have to add a flag in PyType_FromModuleAndSpec, set the flag if (slot->slot == Py_tp_new && slot->pfunc == NULL) in the slots for loop, and then reset tp_new _after_ PyType_Ready.

> The second most important part here is also adding regression tests so this doesn't happen.

I've started adding tests. I'm not sure if I need to wrap them with @cpython_only.

Some of the types are hidden deep inside the implementations, and I have a hard time fetching them. For example _functools._lru_list_elem and _thread._localdummy. Is it ok to leave those out?

Is it ok to skip tests if it is too hard to write them.

Tests should be decorated with @cpython_only because other Python implementations can have working constructors for these types. It is an implementation detail that these types are implemented in C and instances are not properly initialized by default.

Thanks, Serhiy.

Serhiy, would you mind reviewing the PR? bpo-43974 will clean up the changes introduced to setup.py.

New changeset 3bb09947ec4837de75532e21dd4bd25db0a1f1b7 by Victor Stinner in branch 'master':
bpo-43916: Add Py_TPFLAGS_DISALLOW_INSTANTIATION type flag (GH-25721)
https://github.com/python/cpython/commit/3bb09947ec4837de75532e21dd4bd25db0a1f1b7

New changeset 0cad068ec174bbe33fb80460da56eb413f3b9359 by Victor Stinner in branch 'master':
bpo-43916: Remove _disabled_new() function (GH-25745)
https://github.com/python/cpython/commit/0cad068ec174bbe33fb80460da56eb413f3b9359

New changeset 4908fae3d57f68694cf006e89fd7761f45003447 by Victor Stinner in branch 'master':
bpo-43916: PyStdPrinter_Type uses Py_TPFLAGS_DISALLOW_INSTANTIATION (GH-25749)
https://github.com/python/cpython/commit/4908fae3d57f68694cf006e89fd7761f45003447

New changeset 387397f8a4244c983f4568c16a28842e3268fe5d by Erlend Egeberg Aasland in branch 'master':
bpo-43916: select.poll uses Py_TPFLAGS_DISALLOW_INSTANTIATION (GH-25750)
https://github.com/python/cpython/commit/387397f8a4244c983f4568c16a28842e3268fe5d

New changeset 9746cda705decebc0ba572d95612796afd06dcd4 by Erlend Egeberg Aasland in branch 'master':
bpo-43916: Apply Py_TPFLAGS_DISALLOW_INSTANTIATION to selected types (GH-25748)
https://github.com/python/cpython/commit/9746cda705decebc0ba572d95612796afd06dcd4

Pablo & Serhiy, can we close this issue now?

Currently, 33 types explicitly set the Py_TPFLAGS_DISALLOW_INSTANTIATION flag:

* PyStdPrinter_Type
* _curses.ncurses_version type
* _curses_panel.panel
* _dbm.dbm
* _gdbm.gdbm
* _hashlib.HASH
* _hashlib.HASHXOF
* _hashlib.HMAC
* _multibytecodec.MultibyteCodec
* _sre..SRE_Scanner
* _thread._localdummy
* _thread.lock
* _tkinter.Tcl_Obj
* _tkinter.tkapp
* _tkinter.tktimertoken
* _winapi.Overlapped
* _xxsubinterpretersmodule.ChannelID
* array.arrayiterator
* functools.KeyWrapper
* functools._lru_list_elem
* os.DirEntry
* os.ScandirIterator
* pyexpat.xmlparser
* re.Match
* re.Pattern
* select.poll
* sys.flags type
* sys.getwindowsversion() type
* sys.version_info type
* unicodedata.UCD
* zlib.Compress
* zlib.Decompress
* _xxsubinterpreters.ChannelID

---

Static types with tp_base=NULL (or tp_base=&PyBaseObject_Type) and tp_new=NULL get Py_TPFLAGS_DISALLOW_INSTANTIATION flag automatically. Example of 70 static types which gets this flag automatically:

* CArgObject
* EncodingMap
* Generic
* GenericAlias
* PyCapsule
* TaskStepMethWrapper
* Token.MISSING
* _RunningLoopHolder
* _asyncio.FutureIter
* _ctypes.CThunkObject
* _ctypes.StructParam_Type
* _ctypes._CData
* _elementtree._element_iterator
* _io._BytesIOBuffer
* _pickle.Pdata
* _pickle.PicklerMemoProxy
* _pickle.UnpicklerMemoProxy
* _xxsubinterpreters.ChannelID
* anext_awaitable
* async_generator
* async_generator_asend
* async_generator_athrow
* async_generator_wrapped_value
* builtin_function_or_method
* bytearray_iterator
* bytes_iterator
* callable_iterator
* classmethod_descriptor
* coroutine
* coroutine_wrapper
* decimal.ContextManager
* dict_itemiterator
* dict_items
* dict_keyiterator
* dict_keys
* dict_reverseitemiterator
* dict_reversekeyiterator
* dict_reversevalueiterator
* dict_valueiterator
* dict_values
* fieldnameiterator
* formatteriterator
* frame
* generator
* getset_descriptor
* hamt_array_node
* hamt_bitmap_node
* hamt_collision_node
* items
* iterator
* keys
* list_iterator
* list_reverseiterator
* longrange_iterator
* managedbuffer
* member_descriptor
* method-wrapper
* method_descriptor
* moduledef
* odict_iterator
* range_iterator
* set_iterator
* str_iterator
* symtable entry
* tuple_iterator
* types.Union
* values
* weakcallableproxy
* weakproxy
* wrapper_descriptor

I remove the release blocker priority of this issue, since the main issue has been fixed.

According to msg391924, more types should use Py_TPFLAGS_DISALLOW_INSTANTIATION:

* _md5.md5
* _sha1.sha1
* _sha256.sha224
* _sha256.sha256
* _sha512.sha384
* _sha512.sha512

* select.devpoll: I created PR 25751
* select.kevent: it implements a working tp_new method: "{Py_tp_new, select_kqueue},"

* sqlite3.Cache
* sqlite3.Connection
* sqlite3.Cursor
* sqlite3.Node
* sqlite3.Row
* sqlite3.Statement

* _md5.md5
* _sha1.sha1
* _sha256.sha224
* _sha256.sha256
* _sha512.sha384
* _sha512.sha512

I created PR 25753.

It seems like _sqlite3 heap types support regular instantiation and so that no change is needed.

* sqlite3.Cache

    {Py_tp_new, PyType_GenericNew},

* sqlite3.Connection

    {Py_tp_new, PyType_GenericNew},
    {Py_tp_init, pysqlite_connection_init},

* sqlite3.Cursor

    {Py_tp_new, PyType_GenericNew},
    {Py_tp_init, pysqlite_cursor_init},

* sqlite3.Node

    {Py_tp_new, PyType_GenericNew},

* sqlite3.Row

    {Py_tp_new, pysqlite_row_new},

* sqlite3.Statement

    {Py_tp_new, PyType_GenericNew},


$ ./python
Python 3.10.0a7+
>>> import _sqlite3
>>> conn=_sqlite3.Connection(":memory:")

>>> type(conn)()
TypeError: function missing required argument 'database' (pos 1)
>>> conn2 = type(conn)(":memory:")

>>> list(conn.execute("SELECT 1;"))
[(1,)]
>>> list(conn2.execute("SELECT 1;"))
[(1,)]

New changeset 7dcf0f6db38b7ab6918608542d3a0c6da0a286af by Victor Stinner in branch 'master':
bpo-43916: select.devpoll uses Py_TPFLAGS_DISALLOW_INSTANTIATION (GH-25751)
https://github.com/python/cpython/commit/7dcf0f6db38b7ab6918608542d3a0c6da0a286af

Yes, the sqlite3 types are fine. I don't know why I included them in my earlier post.

I cleared the tp_new markings for the sqlite3 types on the Discourse post, since I can edit my posts over there, contrary to here on bpo :)

New changeset 665c7746fca180266b121183c2d5136c547006e0 by Victor Stinner in branch 'master':
bpo-43916: _md5.md5 uses Py_TPFLAGS_DISALLOW_INSTANTIATION (GH-25753)
https://github.com/python/cpython/commit/665c7746fca180266b121183c2d5136c547006e0

> bpo-43916: _md5.md5 uses Py_TPFLAGS_DISALLOW_INSTANTIATION (GH-25753)

With this change, all tests listed in this issue should be fixed.

But I didn't check the whole list of https://discuss.python.org/t/list-of-built-in-types-converted-to-heap-types/8403

Status in Python 3.9.

5 types allow instantiation whereas they must not: BUG!!!

* _tkinter.Tcl_Obj
* _tkinter.tkapp
* _tkinter.tktimertoken
* zlib.Compress
* zlib.Decompress

Example of bug:

$ python3.9
Python 3.9.4
>>> import zlib
>>> obj=zlib.compressobj()
>>> obj2=type(obj)()
>>> obj2.copy()
Erreur de segmentation (core dumped)

---

The remaining types disallow instantiation with different ways.

Static type with tp_base=NULL and tp_new=NULL:

* _dbm.dbm
* _gdbm.gdbm
* _multibytecodec.MultibyteCodec
* _sre.SRE_Scanner
* _thread._localdummy
* _thread.lock
* _winapi.Overlapped
* _xxsubinterpretersmodule.ChannelID
* array.arrayiterator
* functools.KeyWrapper
* functools._lru_list_elem
* pyexpat.xmlparser
* re.Match
* re.Pattern
* unicodedata.UCD
* _xxsubinterpreters.ChannelID

Heap type setting tp_new to NULL after type creation:

* _curses_panel.panel

Static type setting tp_new to NULL after type creation:

* _curses.ncurses_version type
* sys.flags type
* sys.getwindowsversion() type
* sys.version_info type

Define a tp_new or tp_init function which always raise an exception:

* PyStdPrinter_Type
* _hashlib.HASH
* _hashlib.HASHXOF
* _hashlib.HMAC
* os.DirEntry
* os.ScandirIterator
* select.poll

* _tkinter.Tcl_Obj
* _tkinter.tkapp
* _tkinter.tktimertoken

Oops, sorry: in Python 3.9, tp_new is set to NULL after these heap types are created. There is no bug for these 3 types.

I checked " Types converted pre Python 3.9" and "Types converted in Python 3.9" of:
https://discuss.python.org/t/list-of-built-in-types-converted-to-heap-types/8403

(I didn't check "Types converted in Python 3.10" yet.)

These lists are not complete, for example select.kevent was not listed whereas it has a bug.


_struct.unpack_iterator can be modified to use Py_TPFLAGS_DISALLOW_INSTANTIATION: its tp_new method always raises an exception.


Bugs!

* select.kevent: BUG, use {Py_tp_new, PyType_GenericNew} slot which doesn't properly initialize kqueue_event_Object!

Need review:

* _ast.AST: use {Py_tp_new, PyType_GenericNew} and {Py_tp_init, ast_type_init} slots. What happens if tp_new is called without calling tp_init?

Implement tp_new (ok!):

* _abc._abc_data
* _json.Scanner
* _json.Encoder
* select.devpoll
* select.epoll
* select.kqueue
* _random.Random
* _struct.Struct 

Other cases (ok!):

* _ssl.SSLError inherits from OSError and reuses OSError structure (PyOSErrorObject): the inherited tp_new works as expected.
* select.poll: Py_TPFLAGS_DISALLOW_INSTANTIATION

> These lists are not complete, for example select.kevent was not listed whereas it has a bug.

If one of the admins could make that post into a wiki post, it would be open for editing, making it easier to fill the holes in the lists.

> If one of the admins could make that post into a wiki post, it would be open for editing, making it easier to fill the holes in the lists.

Not sure what do you have in mind for the wiki, but the easiest is to open some GitHub issue somewhere or using https://discuss.python.org/

> * _ast.AST: use {Py_tp_new, PyType_GenericNew} and {Py_tp_init, ast_type_init} slots. What happens if tp_new is called without calling tp_init?

I think this is fine since ast_type_init doesn't initialize any C fields and only mutates the object by using PyObject_SetAttr

Something is wrong after commit 3bb09947ec4837de75532e21dd4bd25db0a1f1b7.

When building Python I am getting:

*** WARNING: renaming "_curses" since importing it failed: /home/pablogsal/github/python/master/build/lib.linux-x86_64-3.10-pydebug/_curses.cpython-310d-x86_64-linux-gnu.so: undefined symbol: _PyStructSequence_InitType
*** WARNING: renaming "_curses_panel" since importing it failed: No module named '_curses'

The problem is that the curses module is using a function that requires to be built in the core:

#ifdef Py_BUILD_CORE
extern int _PyStructSequence_InitType(
    PyTypeObject *type,
    PyStructSequence_Desc *desc,
    unsigned long tp_flags);
#endif

The build errors were in the CI, but because Python doesn't complain if it cannot build a module, then we never catched this. I have opened https://github.com/python/cpython/pull/25768 to fix it to unblock the release, since the curses module is broken currently.

New changeset 558df9010915c8fe94f4d7f842e7c5aabbb06b14 by Pablo Galindo in branch 'master':
bpo-43916: Export the _PyStructSequence_InitType to fix build errors in the curses module (GH-25768)
https://github.com/python/cpython/commit/558df9010915c8fe94f4d7f842e7c5aabbb06b14

> Not sure what do you have in mind for the wiki

See https://meta.discourse.org/t/what-is-a-wiki-post/30801

> See https://meta.discourse.org/t/what-is-a-wiki-post/30801

Gotcha, will try to do that as soon as possible

I have transformed https://discuss.python.org/t/list-of-built-in-types-converted-to-heap-types/8403 into a wiki. Tell me if you need some alterations of something is missing.

New changeset ddbef71a2c166a5d5dd168e26493973053a953d6 by Christian Heimes in branch 'master':
bpo-43916: Rewrite new hashlib tests, fix typo (GH-25791)
https://github.com/python/cpython/commit/ddbef71a2c166a5d5dd168e26493973053a953d6

New changeset c2931d31f8ba7cf10044de276018c713ffc73592 by Pablo Galindo in branch 'master':
bpo-43916: Move the _PyStructSequence_InitType function to the internal API (GH-25854)
https://github.com/python/cpython/commit/c2931d31f8ba7cf10044de276018c713ffc73592

Erlend added test.support.check_disallow_instantiation() function in bpo-43988 to write tests for immutable types.

Please, check also the discusion happening here:

https://mail.python.org/archives/list/python-committers@python.org/thread/FHFI7QKWNHAVWVFTCHJGTYD3ZFVEUXDD/

New changeset e90e0422182f4ca7faefd19c629f84aebb34e2ee by Erlend Egeberg Aasland in branch 'main':
bpo-43916: Use test.support.check_disallow_instantiation() in test_tcl (GH-26412)
https://github.com/python/cpython/commit/e90e0422182f4ca7faefd19c629f84aebb34e2ee

FYI, bpo-44087 added the Py_TPFLAGS_DISALLOW_INSTANTIATION flag to sqlite3.Statement.


(Side note: I find the issue title a little bit confusing.)

New changeset 733587011dbb47c2e461188f0574e1cc5288062a by Miss Islington (bot) in branch '3.10':
bpo-43916: Use test.support.check_disallow_instantiation() in test_tcl (GH-26412) (GH-26888)
https://github.com/python/cpython/commit/733587011dbb47c2e461188f0574e1cc5288062a

In Python 3.11, 41 types are declared explicitly with the
Py_TPFLAGS_DISALLOW_INSTANTIATION flag:

* _curses_panel.panel
* _dbm.dbm
* _gdbm.gdbm
* _hashlib.HASH
* _hashlib.HASHXOF
* _hashlib.HMAC
* _md5.md5
* _multibytecodec.MultibyteCodec
* _sha1.sha1
* _sha256.sha224
* _sha256.sha256
* _sha512.sha384
* _sha512.sha512
* _sre.SRE_Scanner
* _ssl.Certificate
* _thread._localdummy
* _thread.lock
* _tkinter.Tcl_Obj
* _tkinter.tkapp
* _tkinter.tktimertoken
* _winapi.Overlapped
* _xxsubinterpreters.ChannelID
* array.arrayiterator
* curses.ncurses_version
* functools.KeyWrapper
* functools._lru_list_elem
* os.DirEntry
* os.ScandirIterator
* pyexpat.xmlparser
* re.Match
* re.Pattern
* select.devpoll
* select.poll
* sqlite3.Statement
* stderrprinter
* sys.flags
* sys.getwindowsversion
* sys.version_info
* unicodedata.UCD
* zlib.Compress
* zlib.Decompress

Can we close this issue? Or is there a remaining task?

> Can we close this issue? Or is there a remaining task?

3.9 is still affected; we should fix those types first.

FYI: There are only two bug-fix releases left for 3.9.

> 3.9 is still affected; we should fix those types first.

I'm against backporting the new type flag, but we can try to set explicitly tp_set to NULL *after* calling PyType_Ready().