Brett, yes, you are welcome to close this issue — Ned quite handily convinced me that coverage code belongs in the "coverage" distribution, not languishing about in the CPython source tree. That solution also quite beautifully solves the copyright problem. So I happily withdraw my request for this feature.

Nick, Brett is working on exactly the sort of devguide improvement that you suggest — not least because the devguide will now need to instruct people in how to build "coverage" so that its C-accelerated tracer is available, which Ned's own patch to "coverage" to cover stdlib tracing uses instead of the Python tracer that I cut-and-pasted into this patch.

Finally, it would be wonderful to have a more formal mechanism for boot-time interventions. I have mentioned before my wish that Python's first action be to open() the executable, check its tail to see if it's a valid zipfile, and if so to try loading and running "startup.py" from that zipfile. Among other things, that would allow single-file distribution of pure-Python applications without the py2exe/py2app mess that prevails in the projects I work with today. But since the whole issue of grabbing control at boot time raises hackles ("why would you want to do that!?"), and I needed something working immediately during the PyCon sprint, I elected to simply adopt "encodings.py" as my way in. It works great, and "coverage" can evolve to an even better mechanism as soon as one becomes available, should anyone want to take the bootup option and run with it.

One final thought: should PyPy etc also implement the same boot protocol, should one be invented, so that all mainline interpreters can be instrumented the same way?