Guido van Rossum <gu...@python.org> added the comment:
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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue45020> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
