2011/8/30 Nick Coghlan <ncogh...@gmail.com> > > 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. > > Sometimes it cannot be done, because big changes produces big patches as well.
I don't see a problem here if the code is well written (as "required" buy the Python community :) and the developer is available to talk about his work to clear some doubts. Regards Cesare
_______________________________________________ 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
