Akismet provides a service and a Python library for calling that service.

The service has 3 possible returns: not spam, likely spam, and definitely spam. Their library maps those 3 to 2: false, true.

So, if you use their library, there’s no way to discriminate between likely spam and definitely spam.

I wouldn’t consider rewriting the library for such a simple change, though. Yes, changing the existing function to return a three-valued result would be a breaking change, but adding a new entrypoint that does that, although technically a breaking change (that’s discoverable by reflection) would not be a breaking change.

I also don’t see why introducing asynchrony would require a rewrite. It could just be bolted on in new entry points, which, I think, the author actually did (“So I made the decision to have two client classes, one sync and one async. As a nice bonus, this meant I could do all the work of rewriting in new classes with new names. That would let me mark the old Akismet class as deprecated but not have to immediately remove it or break its API”)