Rewriting a 20-year-old Python library

I have not looked at the code and I'm not saying the author is wrong, but this explanation makes absolutely no sense to me:

if akismet_client.comment_check(..) [...] But the akismet Python client couldn’t usefully expose this, since the original API design of the client chose to have this method return a two-value bool instead of some other type that could handle a three-value situation. And any attempt to fix it would necessarily change the return type, which would be a breaking change.

Here:

if akismet_client.comment_check2(..) == ...

Completely backwards compatible, and the people who care for this feature would have to think about their usage anyway.

Yes, it's ugly, no, I'm not telling them not to rewrite their library. Just don't provide reasons that don't make sense. (or phrase them so it makes sense)

I'd even go so far as saying that adding another function could be a really bad idea if it's some method that is deeply nested in some project in several ways and would need tons of refactoring... but by the description on PyPI it's the single method that a user of the client would call.

(Also I'm still shaking my head at this API not returning like 0,1,2 but true/false and a header.. I'm sorry you had to endure this, OP - this could be a textbook example for the for the worst tri-state bool invented)

A few days ago I saw a story about an open source tool that was rewritten (with AI help) and had its license changed from LGPL to MIT. The case in this post feels similar (but no AI involved this time and no license change): should this library also be renamed to reflect that rewrite?

Anyway, I found it really interesting to read through the decision making process behind the rewrite, not just the final result. I have always found async in Python a bit tricky compared to languages like Go, and this post confirms that feeling.