> 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.