Gregor, thanks for sharing your experience!

I guess freezing the entire stdlib instead of just a smattering of modules (like we do here) exacerbated the problems in your case.

Builtin modules (such as sys or time) don't have a __file__ attribute either, and nobody has ever complained about this (that I know of). I wonder how far our backwards compatibility guarantee should go -- would this mean we cannot turn any stdlib module written in Python into one written in C (or Rust :-)?

It would be more serious if standard tests fail, but I haven't seen any evidence -- the tests all seem to pass for Eric's PR.

Now, if there are stdlib modules that reference their own __file__ and we want to freeze those, we should switch those to using ResourceReader or importlib.resources of course.

I agree that we should shore up the frozen importer -- probably in a separate PR though. (@Eric: do you think this is worth its own bpo issue?)

I also noticed the linear scan (and it's being called up to 5 times for modules that *aren't* frozen :-). strcmp is *very* fast (isn't it a compiler intrinsic?), but perhaps we should time it and if it seems a problem we could sort the array and do a form of bisection. (A slight problem is that there's an API to mutate the list by changing a pointer, so we may have to detect when the pointer has changed and recompute the size by doing a scan for the sentinel, once.)

Unfortunately I don't think we're yet in a world where we can accept any dependencies on Rust for CPython itself, so we would have to rewrite your example implementations in C if we wanted to use them.