Raymond Hettinger added the comment: A few thoughts:
* This is very unlikely to come up in real code. Accordingly, I've marked this a low priority -- the peepholer is over a decade old and seems to work-out fine in actual practice. * The user explicitly asked for 1 << 500000000 to be computed. At some point, either during compilation or during execution, a large object is going to be produced. * The binops folding in peephole.c was originally much simpler and did not recursively combine results. The patch that added the recursive application of constant folding added a lot of complexity, but it demonstrated very little real world benefit, and it opened the door to examples like this where the computer is being explicitly told to do a lot of work. Perhaps constant folding should be reverted to its simpler state. * We could do a size check after each folding step and abandon folding when the size hit some limit. I'm not sure that is worth it though. Someone can just add more zeros and then complain that the compilation step took a lot of time and memory without producing any benefit. * We could try to detect an expensive computation before it is run, but in general that is hard to do right and it adds yet more complexity to something that started-out simple. * One of the design objectives for the peephole transformations was to keep it fast and slim rather than trying to be all things to all people. Burdening the optimizer with insanity checks just slows down the compilation of normal, sane code. * With sum(), Guido and Alex took the position that users should be blocked from using it with list-of-strings, but we didn't do block other unfavorable possibilities like a list-of-lists. The rationale was that the list-of-strings was too tempting and likely but that other cases weren't common or easy to detect. Likewise for Tim and I, the early decision for the peephole optimized (the decision being second guessed by this issue) was that large strings were easy to detect and likely enough to warrant extra code but that numeric folding issues were much less likely and didn't warrant extra code. * Constant folding was introduced before the AST branch. Once that branch landed, it has been a long standing objective to move constant folding out of the peepholer and into the AST stage. Accordingly, we've tried to refrain from further build-outs of constant folding. It is a pit of snakes. If someone really cares about this, they should work on an AST transformation. * Programming languages are different from applications. Users are allowed to explicitly create code that tells the computer to do something resource intensive and there are a myriad of ways to do so. In general, it will be difficult to prevent the execution of such code without unduly burdening execution of normal code. ---------- nosy: +rhettinger priority: normal -> low type: -> resource usage versions: +Python 3.7 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30293> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
