On 11/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > [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". >
Fair enough. > > > 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. Huh? But Phillip is suggesting a new opcode that is essentially the same as my proposal but naming it differently and saying the bytecode should get changed directly instead of having the eval loop handle the semantic differences based on whether -O is being used. -Brett _______________________________________________ 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
