-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Warsaw wrote:
On Feb 26, 2010, at 02:55 PM, Brett Cannon wrote:
Here is a question for Barry to think about if he decides to move forward with all of this: would mixed support for both bytecode-only and source/bytecode be required for the same directory, or could it be one or the other but not both? Differing semantics based on what is found in the directory would make the path hook more expensive (which is a one-time cost per directory), but it would cut stat calls in the finder in half (which is a cost made per import).
It seems a bit magical to me, and the rules a bit difficult to predict. For example, what would be the trigger to enable bytecode-only support for a package directory? Would it be the absence of an __init__.py file? What if some .pyc files had .py file but not all of them? Wouldn't the trigger depend on import order?
OTOH, maybe you're on to something. Perhaps we could add a flag to the package's namespace to turn this on. You'd have to include the __init__.py to get things going, but after that, everything else in the package could be .pyc-only.
Why not just leave the code for import in the package directory as it is today, where .pyc files are already importable in the absence of a .py file? As long as file in the cachedir are *not* importable without the source, both sides win, AFAICT: most people will no longer have .pyc's in their package direoctories, and those who want them can get them, thorugh some means (moving from the cachedir, or disabling the cachedir feature). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuJUXkACgkQ+gerLs4ltQ76UACeMtgUz+mxmxlU1wLgl58R4ZA0 aVMAoKEmVG0D8a37Ftag6srPQSWfptON =49Tz -----END PGP SIGNATURE-----