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. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20100227/fdcda3cd/attachment.pgp>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4