Support for recording PEP 234 style iterators

[garybernhardt]

Imported from BitBucket:

Reported by Anonymous, created 6 months ago.

Specifically the syntax that replaces the has_key() method on dictionaries.

In [41]: d.has_key('str') Out[41]: <Dingus dingus_15795344.has_key()>
In [42]: 'str' in d Out[42]: False
In [43]: d.calls Out[43]: [('has_key', ('str',), {}, <Dingus dingus_15795344.has_key()>)]

http://www.python.org/dev/peps/pep-0234/

I may be missing something, but it seems like iterators that use the in keyword are not recorded, I haven't looked into implementing this myself yet, but would be happy to give it a shot.

Gary Bernhardt / garybernhardt

It looks like we just never defined the contains method. Patches are always welcome! :) I'll probably get to this eventually, but it hasn't been an itch I've had just yet. :)

flzz

Added attachment dingus_issue_11.patch.
Not sure if this covers the bases appropriately, but its working for my needs at the moment :)

Anonymous

Is it likely that this patch will be merged in?

[garybernhardt]

The patch in question:

diff -r 2c96882a32d1 dingus.py
--- a/dingus.py Sat May 29 15:16:50 2010 -0700
+++ b/dingus.py Fri Jun 04 20:32:27 2010 -0400
@@ -275,16 +275,20 @@ class Dingus(object):
         return return_value

     def __setitem__(self, index, value):
         child_name = '[%s]' % (index,)
         self._log_call('__setitem__', (index, value), {}, None)
         self._remove_child_if_exists(child_name)
         self._existing_or_new_child(child_name, value)

+    def __contains__(self, value):
+        self._log_call('__contains__', (value,), {}, None)
+        return True
+
     def _create_operator(name):
         def operator_fn(self, other):
             return self._existing_or_new_child(name)
         operator_fn.__name__ = name
         return operator_fn

     def _operators():
         operator_names = ['add', 'and', 'div', 'lshift', 'mod', 'mul', 'or',
diff -r 2c96882a32d1 tests/test_dingus.py
--- a/tests/test_dingus.py  Sat May 29 15:16:50 2010 -0700
+++ b/tests/test_dingus.py  Fri Jun 04 20:32:27 2010 -0400
@@ -232,16 +232,23 @@ class WhenAccessingItems:
         assert dingus.calls('__getitem__', 'item').one()

     def should_log_access_after_initial_item_read(self):
         dingus = Dingus()
         for _ in range(2):
             dingus['item']
         assert len(dingus.calls('__getitem__', 'item')) == 2

+    def should_log_access_after_contains_iterator(self):
+        dingus = Dingus()
+        dingus['item'] = 'value'
+        for _ in range(2):
+            'value' in dingus
+        assert len(dingus.calls('__contains__', 'value')) == 2
+
     def should_accept_tuples_as_item_name(self):
         dingus = Dingus()
         assert dingus[('x', 'y')]


 class WhenSettingItems:
     def setup(self):
         self.dingus = Dingus()

[garybernhardt]

I've pushed a "contains_support" branch with this patch and some elaboration on it. There's a failing test that illustrates the problem: dictionaries and lists handle containment differently. For dictionaries, "x in y" is a query on the keys; for lists, it's a query on the values.

If Dingus actually remembers the keys that were set and gives real replies about containment, it has to choose one of these behaviors. Either choice is wrong: dinguses are supposed to be generic. I guess that the only reasonable solution is make __contains__ return a new dingus like any other method, which means dinguses will always claim to contain everything.

[garybernhardt]

Michael Foord says:

@garybernhardt contains return value is always cast to a bool, so can't return an arbitrary object. (Sucky IMO but there you go.)

I guess returning a Dingus is out; it'd be the same as returning True.