GeezerVison

I found a bug in PyUnicodeEncodeError_GetStart where constructing an UnicodeEncodeError with start = 0 and an empty string object raises an assertion error.

I think you should open an issue and create a separate pr with bugfix.

I think you should open an issue and create a separate pr with bugfix.

Good idea. I separated the commit so that it can easily be cherry-picked (hehe).

So we need a way to unregister the codecs. Otherwise I don't know how to do it... (would reloading the module work? or do you want an API for explicitly unregistering an error handler?)

an API for explicitly unregistering an error handler?

That would be nice, yes. It should be a separated PR if you want to work on that.

I'm not sure if it's strictly needed right now if your test creates/loads a separated extension just for C tests. But the test should not leak :-)

That would be nice, yes. It should be a separated PR if you want to work on that.

I'll work on that tomorrow (I wanted to work today but I have no energy at all).

I'm not sure if it's strictly needed right now if your test creates/loads a separated extension just for C tests

Before working on the above feature, I'll try to see how I can make it work without it. (at least we should be able to check if it leaks...).

So, the issue is with _testcapi.codec_namereplace_errors and the setUp(). I'll try to see what happens out there.

So something is wrong when I add those lines and uses -R ::

self.enterContext(import_helper.isolated_modules())
self.enterContext(import_helper.CleanImport('codecs'))

(Still searching where it leaks...)

So I managed to fix the leaks. The crash seems to be because of this line in PyCodec_NameReplaceErrors:

if (ucnhash_capi->getname(c, buffer, sizeof(buffer), 1))

I have no idea why no using fresh imports seem fine. However, the getname pointer is different just before it crashes.

Why do you need a fresh import?

I don't need them anymore so I can remove them normally. I'll now work on the PR for removing a registered error handler so that we can run the test suite. For now, the PR is not ready since there will be a leak due to the error handler being held.

Mmh, apparently tests were backported for the other modules, but this one relies on the internal private feature of being able to unregister error handlers. I don't really want to add it 3.12 and 3.13 so I think we can keep these tests for 3.14+.

Yeah, it makes sense to not backport these tests.

Merged, thanks for this nice enhancement!