[Guido] > > However, this would be a major pain for the standard library and other > > shared code -- there it's really nice to have a cache for each of the > > optimization levels since usually regular users can't write the > > .py[co] files there, meaning very slow always-recompilation if the > > standard .pyc files aren't of the right level, causing unacceptable > > start-up times. [Brett] > What if PEP 304 came into being? Then people would have a place to > have the shared code's recompiled version stored and thus avoid the > overhead from repeated use.
Still sounds suboptimal for the standard library; IMO it should "just work". > > The only solutions I can think of that use a single file actually > > *increase* the file size by having unoptimized and optimized code > > side-by-side, or some way to quickly skip the assertions -- the -OO > > option is a special case that probably needs to be done differently > > anyway and only for final distribution. > > One option would be to introduce an ASSERTION bytecode that has an > argument specifying the amount of bytecode for the assertion. The > eval loop can then just igonore the bytecode if assertions are being > evaluated and fall through to the bytecode for the assertions (and > thus be the equivalent of NOP) or use the argument to jump forward > that number of bytes in the bytecode and completely skip over the > assertion (and thus be just like a JUMP_FORWARD). Either way > assertions becomes slightly more costly but it should be very minimal. I like Phillip's suggestion -- no new opcode, just a conditional jump that can be easily optimized out. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
