On Tue, Aug 30, 2011 at 4:22 PM, Eli Bendersky <eli...@gmail.com> wrote: > On Tue, Aug 30, 2011 at 08:57, Greg Ewing <greg.ew...@canterbury.ac.nz> > wrote: > Following this argument to the extreme, the bytecode evaluation code of > CPython can be simplified quite a bit. Lose 2x performance but gain a lot of > readability. Does that sound like a good deal? I don't intend to sound > sarcastic, just show that IMHO this argument isn't a good one. I think that > even clever optimized code can be properly written and *documented* to make > the task of understanding it feasible. Personally, I'd love CPython to be a > bit faster and see no reason to give up optimization opportunities for the > sake of code readability.
Yeah, it's definitely a trade-off - the point I was trying to make is that there *is* a trade-off being made between complexity and speed. I think the computed-gotos stuff struck a nice balance - the macro-fu involved means that you can still understand what the main eval loop is *doing*, even if you don't know exactly what's hidden behind the target macros. Ditto for the older opcode prediction feature and the peephole optimiser - separation of concerns means that you can understand the overall flow of events without needing to understand every little detail. This is where the request to extract individual orthogonal changes and submit separate patches comes from - it makes it clear that the independent changes *can* be separated cleanly, and aren't a giant ball of incomprehensible mud. It's the difference between complex (lots of moving parts, that can each be understood on their own and are then composed into a meaningful whole) and complicated (massive patches that don't work at all if any one component is delayed) Eugene Toder's AST optimiser work that I still hope to get into 3.3 will have to undergo a similar process - the current patch covers a bit too much ground and needs to be broken up into smaller steps before we can seriously consider pushing it into the core. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
