OK, looks like I've lost track of what this thread is about then. Sorry for the noise. Paul On 18 October 2017 at 16:40, Koos Zevenhoven <k7hoven@gmail.com> wrote:
On Wed, Oct 18, 2017 at 6:36 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 18 October 2017 at 16:27, Koos Zevenhoven <k7hoven@gmail.com> wrote:
So you're talking about code that would make a C-implemented Python iterable of strictly C-implemented Python objects and then pass this to something C-implemented like list(..) or sum(..), while expecting no Python code to be run or signals to be checked anywhere while doing it. I'm not really convinced that such code exists. But if such code does exist, it sounds like the code is heavily dependent on implementation details.
Well, the OP specifically noted that he had recently encountered precisely that situation:
""" I recently came across a bug where checking negative membership (__contains__ returns False) of an infinite iterator will freeze the program. """
No, __contains__ does not expect no python code to be run, because Python code *can* run, as Serhiy in fact already demonstrated for another purpose:
On Wed, Oct 18, 2017 at 3:53 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
18.10.17 13:22, Nick Coghlan пише:
2.. These particular cases can be addressed locally using existing protocols, so the chances of negative side effects are low
Only the particular case `count() in count()` can be addressed without breaking the following examples:
class C: ... def __init__(self, count): ... self.count = count ... def __eq__(self, other): ... print(self.count, other) ... if not self.count: ... return True ... self.count -= 1 ... return False ... import itertools C(5) in itertools.count() 5 0 4 1 3 2 2 3 1 4 0 5 True
Clearly, Python code *does* run from within itertools.count.__contains__(..)
––Koos
-- + Koos Zevenhoven + http://twitter.com/k7hoven +