On Wed, Oct 18, 2017 at 10:13 PM, Serhiy Storchaka <storch...@gmail.com> wrote:
> 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. -- Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven +
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
