gh-119192: Remove #ifndef SLOW_SUM check from sum(), use #if 1

[sobolevn]

Or I might be wrong and it is actually useful :)
In this case, we might want to document it maybe? Or add to ./configure?

• Issue: SLOW_SUM flag in sum builtin #119192

[gvanrossum]

I don't think I own this file any more, and I have no idea what this is about -- maybe @tim-one does? It looks like the git blame isn't useful -- the people blamed are just the ones who merged a branch.

[tim-one]

I already commented on the Issue Report: no strong opinion, but I'd personally change it to #if 1. I can understand why Raymond wants an easy way to turn it off (for investigating stuff), but editing 1 character is easy enough for me 😉, and there's no possibility then that other code could #define the name by mistake. Defer to Raymond, though. (It was absolutely never intended that this be user-configurable.)

[gvanrossum]

Okay let's just leave it alone.

[sobolevn]

Thanks a lot for the feedback, I followed the idea described in #119192 (comment)

So, it is up to module owners to decide: to close this PR or to use #if 1 (which I prefer, since using undocumented names can be problematic).

[erlend-aasland]

I think Tim's suggestion of making this #if 1 instead of using a macro is fine. FWIW, I would never leave such a personal debugging tool in the code base.

[erlend-aasland]

I'd skip news for this, FWIW.

[gvanrossum]

I still vote for leaving it as is. In the future, people who are curious about this will find the issue here and that will explain it to them.

[rhettinger]

FWIW, the current flag was recently useful to me while testing the improved accuracy summation feature. An #if 1 would have make testing much harder because I would have needed have needed to constantly sync two nearly identical builds to see which tests passes for each path.

Also, the alternate code paths have been present for almost two decades -- there isn't a real world problem being solved here.

BTW, is not a "personal debugging tool". Any developer who wants to do future work on this (perhaps adding a high-accuracy path for complex numbers) would benefit. There is a forseeable recurring need to be able to compare a specialized path with a base case.