[Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

[Raymond Hettinger]

There are separate social, strategic, and tactical questions.

The social question:  if the person who designed, implemented, and maintained the optimizer recommends against a patch and another committer just checks it in anyway, do we care?  I've taken responsibility for this code and have treated it will a good deal of care.  I don't believe the patch should go in because the risk/reward ratio is too low and because a better solution exists.

The strategic question:  constant folding in the peephole optimizer pre-dates the AST branch.  When AST landed, there was general agreement among myself and those involved that any future optimizations which could be done with the AST, should be done there.  It is the correct technological solution.  

At one point, we had strategic agreement to stop building-out the peepholer in any significant way.   In fairness to Antoine, the conversations took place several years before he became a committer.  The strategic question is do we want to come to that agreement again?  Can we agree to not have significant changes to the peepholer, to treat it with great care and restraint?   This patch doesn't have to go in.  Py3.3 won't be out for 18 to 24 months anyway.  There is a lot of time to do the job right and not add weight to a house of cards.

The tactical question:  is this particular patch correct?  Maybe it is.  I don't know, I didn't get past all the new macros.  I do know that I could have whipped up something similar years ago but chose not to based on advice from Thomas, Andrew, Tim, and Guido.   The only change since then is that there is a newer committer doesn't buy into that reasoning.

Constant folding is the most complex part of the optimizer.  Why would we add to it, when a better and more reliable approach exists?  The patch hasn't even been demonstrated to be necessary in any real-world code.  


Raymond