@encukou@corona10 could you take a look? Thanks!

Thank you!
My main worry here is that we might get into a situation likesys.version/sys.version_info, where the earlier “stringly typed” attribute has a better name.
Are we likely to need something likebackend.name &backend.version in the future? If we do, will it be OK to keepbackend and a newbackend_version?
Or am I overthinking this?

Could you add a test to assertbackend is either"readline" or"editline"?

Thank you! My main worry here is that we might get into a situation likesys.version/sys.version_info, where the earlier “stringly typed” attribute has a better name. Are we likely to need something likebackend.name &backend.version in the future? If we do, will it be OK to keepbackend and a newbackend_version? Or am I overthinking this?

Could you add a test to assertbackend is either"readline" or"editline"?

Very helpful insight! From my observation, the difference between different versions of the same library is significantly less important than the difference between the two libraries. I can't guarantee that the version of the backend will not ever be used at all in the future, but I would guess that's a very rare case. Bothreadline andeditline seems to be relatively consistent between versions.

That being said, I think using a single string type forreadline.backend is reasonable, and it probably makes the life easier for the users compared to having a(name, version) tuple for the attribute and the users would have to doreadline.backend[0] == 'readline' in most of the cases.

If in the future,readline oreditline has a breaking change in some version that affects many users, having areadline.backend_version is not the end of the world.

I think we are done with the review for this PR? We should merge this before#107748 so it can use thebackend instead of checking__doc__

One more thing: the docs entry needs aversionadded. I updated the PR directly to avoid a round of review ping-pong; hope you don't mind.

(And I fell into the trap of thinking this is simple enough to use GitHub UI rather than a local clone...)

Thanks for the quick review!