This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients gslavin, ncoghlan, rhettinger, steven.daprano, terry.reedy, vstinner, wim.glenn
Date 2016-09-20.03:57:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1474343850.54.0.62094582029.issue26351@psf.upfronthosting.co.za>
In-reply-to
Content
I think this needs more discussion on python-dev before going down this path.

In reality, we have many places that have "long running" C code when fed extreme arguments.  In practice, we almost never have a problem with these except for cute toy bug reports.   To "fix" this, we would need to alter all possible long running data consumers or alter all possible long running data producers.  This kind of change is hard to test, gums up the code, and hinders future maintainability for near zero benefit to ordinary users.

    min(range(100000000000))    # There a lots of places like this

The proposed patch is indelicate about the addition of signal checking.  It check on every single iteration right in the middle of most highly optimizied, tightest, most speed critical loops in Python, making every use pay a cost for something almost no one will ever benefit from.
History
Date User Action Args
2016-09-20 03:57:30rhettingersetrecipients: + rhettinger, terry.reedy, ncoghlan, vstinner, steven.daprano, wim.glenn, gslavin
2016-09-20 03:57:30rhettingersetmessageid: <1474343850.54.0.62094582029.issue26351@psf.upfronthosting.co.za>
2016-09-20 03:57:30rhettingerlinkissue26351 messages
2016-09-20 03:57:29rhettingercreate