[Python-Dev] Python 3 optimizations continued...

[Cesare Di Mauro]

2011/8/30 Nick Coghlan <ncoghlan at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110831/563c5e40/attachment.html>