Nick Coghlan added the comment:

Antoine: The scaling is deliberate higher in the recursion limit finder because 
we just want to ensure it hits the recursion limit (or blows the stack, if the 
scaling is wrong). In the tests, I cut it finer because I wanted to ensure we 
were straddling the allowed/disallowed boundary fairly closely in order to 
properly test the code that accounts for the *existing* recursion depth when 
initialising the compiler's internal state.

Mark: same answer I gave Antoine earlier. Without the scaling factor, a test 
fails. If you want to advocate for removing or changing that test instead, 
track down why it was added and provide a rationale for why it's no longer 
applicable. However, before you invest too much time in that, note that the 
trees generated by binary operators of the same precedence in CPython are *not* 
balanced (IIRC, the LHS is handled as a leaf expression), thus they also suffer 
from this recursion problem (if you look at the patch I committed, I added an 
extra test beyond those Andrea provided: a multiplication expression with a 
ridiculously large number of terms). I agree that path is the only one 
generated code is likely to hit, though, which is why I added a specific test 
for it.


Python tracker <>
Python-bugs-list mailing list

Reply via email to