18.10.17 17:48, Nick Coghlan пише:
1. It will make those loops slower, due to the extra overhead of checking for signals (even the opcode eval loop includes all sorts of tricks to avoid actually checking for new signals, since doing so is relatively slow)
2. It will make those loops harder to maintain, since the high cost of checking for signals means the existing flat loops will need to be replaced with nested ones to reduce the per-iteration cost of the more expensive checks
3. It means making the signal checking even harder to reason about than it already is, since even C implemented methods that avoid invoking arbitrary Python code could now still end up checking for signals
I have implemented signals checking for itertools iterators. [1] The overhead is insignificant because signals are checked only for every 0x10000-th item (100-4000 times/sec). The consuming loops are not changed because signals are checked on the producer's side.
[1] https://bugs.python.org/issue31815 Nice! Though I'd really like a general solution that other code can easily adopt, even third-party extension libraries.