Idle bytecode query on apparently unreachable returns

sxanth at sxanth at
Tue Oct 11 12:01:34 CEST 2005

>What puzzles me, though, are bytecodes 17, 39 and 42 - surely these aren't 
>reachable? Does the compiler just throw in a default 'return None' 
>epilogue, with routes there from every code path, even when it's not 
>needed? If so, why?


pyc ( can already remove that
unused code since June.

As for "why", I guess that there is a lot of room for optimizing
the bytecode but it's a PITA doing all of it in the current internal
compiler. And so developers simply don't care about it.
Maybe the ast-branch would make it easier to start generating
optimal bytecode. On the other hand, the 'compiler module'
produces bad bytecode (for example it miscalculates the 'stacksize'
of functions and as a result the generated functions are slow), it
doesn't use LIST_APPEND, and it doesn't even do the simple peephole
optimizations of the intenal compiler!

In the latest version 0.8 to-be-released, pyc does many more bytecode
optimizations that give a +5% to pystone and it can also bring
generator expressions and decorators to python 2.3.

0.8 is stuck on the conditional. We can bring the conditional expression
from the __future__ to users of 2.3/2.4 but I'm not sure people really
like the "T if C else F" syntax over "C ? T : F".

The argument: "python uses 'and'/'or' instead of &&/|| and therefore
it should also use 'if-else' instead of '?:'", just doesn't apply.
And generally this is one of those things that you will never find
the argument that proves which is the right choice. In these cases
you do what you *LIKE* more.

Perhaps a vote would be in order considering the this-or-that
nature of the conditional expression :)


This message was sent through the TEI of ATHENS by means of NOC. 

More information about the Python-list mailing list