On Feb 28, 2010, at 11:07 PM, Nick Coghlan wrote:
While the PEP is right in saying that a bytecode-only import hook could be added, I believe it would actually be a little tricky to write one that didn't severely degrade the performance of either normal imports or bytecode-only imports. Keeping it in the core import, but turning it off by default seems much less likely to have unintended performance consequences when it is switched back on.
Except that even users of bytecode-only imports probably don't want or care about that for *every* package directory. So really, all-or-nothing hits them too. One option to help with that is to have a flag or marker in a package's __init__.py that signals pyc-only imports for that package directory. It's getting complicated again. ;)
Another option is to remove bytecode-only support from the default filesystem importer, but keep it for zipimport (since the stat call savings don't apply in the latter case).
I'd be okay with this, but even here I'd argue that it would be fine to require the source files by default. The primary use case I've seen mentioned for pyc-only imports is to make it more difficult for users to accidentally shoot themselves in the foot. I think the very presence of a zip file for importing is enough without the extra step of removing the source. But that's just me. :) -Barry