[Python-Dev] Inconsistent behaviour in import/zipimport hooks

Guido van Rossum guido at python.org
Thu Nov 10 01:35:14 CET 2005


[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/)


More information about the Python-Dev mailing list