Guido van Rossum <gu...@python.org> added the comment:
> At this point, here are the open questions I'm seeing: > + The editing-stdlib-.py-files problem: [...] > + Compatibility: [...] ? + Penalty for too many frozen modules: [...] > FWIW, I think the ideal mechanism for a dev build will be to opt in to using > frozen modules (instead of the source modules). Otherwise it is too easy for > the unaware contributor to waste substantial time figuring out why their > changes are not getting used. Agreed. I don't care much about people (even myself) editing installed modules. But I care a lot about people who do a git checkout and build from source editing modules and testing them without doing an install (Personally I never install what I build from source except to test the installation process.) > Consequently, here's my order of preference for ignoring frozen modules: > 1. use Py_DEBUG as an opt-out flag > (if we think contributors are editing stdlib modules on a build without > Py_DEBUG then that isn't good enough) > 2. automatically skip frozen modules if it's a dev build, with an explicit > configure flag to opt in to frozen modules. I propose to only opt in by default in **PGO builds**. After all what we're doing is another extreme optimization. It should always be possible to opt in using some -X flag (e.g. to debug the freeze import loader) and it should also always be possible to opt *out* (for those cases where you want to edit an installed stdlib module in-place in anger). I don't know how the -X mechanism works exactly but probably we could make the spelling python -X freeze=on|off with a dynamic default. ---------- _______________________________________ 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
