New submission from Brett Cannon: The reason the magic number exists in .pyc files is because back in Python 2 we only had a single .pyc file per module, which meant if you suddenly switched versions of Python you needed a way to know that the .pyc file was wrong for the running version of Python.
This is not the case in Python 3. Thanks to __pycache__ directories we have separate .pyc files per release version of Python (we also have .pyc files for each optimization level of Python). If we changed the sys.implementation.cache_tag to include the bugfix version -- and maybe even release level -- then the magic number wouldn't be necessary for users. It does make developing bytecode a little bit more difficult for core developers since they will have to clear out their .pyc files during development, but users wouldn't be affected. Now I don't know if this is really worth the simplification it provides. I don't think it's worth the compatibility break for any code that may be reading .pyc files and I doubt there is any measurable performance benefit. But the realization struck me and I figured I should at least write it down in case anyone else thinks of it. ---------- components: Interpreter Core messages: 257705 nosy: brett.cannon, eric.snow, ncoghlan priority: low severity: normal stage: test needed status: open title: Consider dropping magic number for more detailed .pyc file name type: enhancement versions: Python 3.6 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26042> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
