>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?
Hi. pyc (http://freshmeat.net/projects/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. [OT] 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 :) st. ---------------------------------------------------------------- This message was sent through the TEI of ATHENS by means of NOC. -- http://mail.python.org/mailman/listinfo/python-list