import _platform never fails. But if we delete code, it will be unconciously recovered whenever we update platform.py from recent CPython version. deleted code is not easy to track.
I'd like to keep the original code as much as possible not to mislead library updating process.

I now think try: import _platform is not necessary. Instead of it, from _platform import * at the bottom of the platform.py will work by overriding the python attributes.

Funny, I was thinking that too, earlier, and gave it a try. (It worked fine.) But I figured there was a reason/preference for not doing it that way in the earlier versions. Anyway, I'll go ahead with that.

(This will also take care of those tests that failed, that I forgot to check first -- oops! I'm curious though how the pre-3.10.6 version got through with the same issue. There's a cache variable that was removed, that the test tries to clear.)

BTW, there are those two TODO items in the prior version that short-circuited a couple things. Let me take a closer look at those to see if they're important. I'll submit the change after I check those.

But I figured there was a reason/preference for not doing it that way in the earlier versions.

There could be an historical issue we couldn't do. The change made long time ago and we had a huge progress on compatibility. Maybe we just couldn't make the best decision for every time.

I confirmed, the old TODO's weren't necessary.

However... The test now fails because they're doing some "interesting" things in test_platform.py, setting sys.version and sys.platform to fake out the platform.* functions. We could probably support this in platform.rs (have it check sys.version and sys.platform). But what they're doing isn't really a documented feature, and the rust code will get pretty convoluted. But what do you think? Should I just modify the test to handle our rust overrides better? (That link you sent earlier about updating tests was very informative. Thanks.)

(I have other ideas that would involve changes to platform.py. But since we're trying to minimize changes there...)

Latest commit assumes that the simplified approach (just the import at the end) and an expectedFailure on that specific test is fine. Happy to make adjustments if necessary.

I am really sorry, but after reviewing the failing test, I think _platform was introduced only for historical reason and now we are ready to leave it to past. This is not what I expected when I first reviewed this issue.
I had a busy week but now I can spend more time for RustPython. If you want to look for an issue to step into RustPython, I will try to find one. Please leave a comment.

Understood, no problem. (Regarding other issues to work on, I was going to do one of the number protocol items when I get a chance later.)