@vstinner please review

While this change is correct, I'm not excited by leaking a new heap type at Python exit.

Would you mind to attempt to add a module state to the module, and pass to all functions which use the UCD_Type? (without converting the UCD_Type to a heap type) The module state can be an empty structure, or add a "int dummy" just to make it non-empty.

While this change is correct, I'm not excited by leaking a new heap type at Python exit.

Would you mind to attempt to add a module state to the module, and pass to all functions which use the UCD_Type? (without converting the UCD_Type to a heap type) The module state can be an empty structure, or add a "int dummy" just to make it non-empty.

@vstinner This is going to a large set of changes, almost as large as the original PR, because I have to introduce an additional layer for all methods which are used by both the module and the type. I don't see how this will help with the leak

This PR is outdated, unicodedata got many changes in the meanwhile. I proposed one approach to convert unicodedata to multi-phase init in https://bugs.python.org/issue42157 I close this PR. Once PR #22990 will be merged, I will propose a PR to finally convert the module to multi-phase init. Sorry for the misunderstanding, but this extension module is way more complex than other extensions, and I didn't spot all corner cases at the first review. See the bpo for the list of all issues and my proposal.

@vstinner no problem, I agree it is complex.