Nick Coghlan added the comment:

While I agree with Raymond regarding the performance implications if this isn't 
handled carefully, I think we're also getting to a point where better 
accounting for signal handling latency in inner loops is something that could 
be considered for 3.7 - the benchmarking infrastructure being built out to 
measure performance optimisations would also allow overhead tuning of a 
"batched iteration" idiom where signals were checked for either every N 
thousand iterations, periodically based on time, or some combination of the two.

Benchmarking to measure the speed impact is going to be essential, though - 
this is a case where changing the behaviour is clearly possible, so the key 
questions are whether or not the resulting runtime overhead can be made low 
enough to be deemed acceptable, and whether or not it can be done in a way that 
doesn't make the affected parts of the code base effectively unreadable.


Python tracker <>
Python-bugs-list mailing list

Reply via email to