find out if the `in` operator can be used

Question

What is the simplest (and most elegant) way, to find out if the in operator can be used in python? If I open a python shell and type in:

"" in 2

it prints:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument of type 'int' is not iterable

according to the python-docs an iterable is:

container.iter()

Return an iterator object. The object is required to support the iterator protocol described below. If a container supports different types of iteration, additional methods can be provided to specifically request iterators for those iteration types. (An example of an object supporting multiple forms of iteration would be a tree structure which supports both breadth-first and depth-first traversal.) This method corresponds to the tp_iter slot of the type structure for Python objects in the Python/C API.

so

hasattr([], "__iter__") and hasattr({}, "__iter__")

return true as expected, but

hasattr("test_string", "__iter__")

returns false. But I can use

"test" in "test_string"

without any problems.

By elegant I refer to NOT use a try-except solution

Answer 1

The iterator protocol doesn't actually require a type to support __iter__. It requires a type to either support __iter__, or __getitem__ with sequential integer arguments starting from 0. See the iter function for the best explanation of this in the docs.

So, hasattr(x, "__iter__") will give you false negatives if testing whether something is iterable.

So, how can you do this? Well, the right way, even if you don't like it, is:

try:
    i = iter(x)
except TypeError:
    # not iterable

---

Also, note that, as the docs for hasattr explain:

This is implemented by calling getattr(object, name) and seeing whether it raises an exception or not.

So, really, you're not avoiding exceptions at all; you're just coming up with a more convoluted way to raise an exception and hide that fact from yourself.

---

But meanwhile, iteration is a red herring in the first place. The in operator is implemented with the __contains__ method. Container types that don't define a __contains__ method will fall back to iterating and comparing, but types aren't required to implement it that way. You can have a __contains__ that's much faster than iterating could be (as with dict and set); you can even be a container without being an iterable. (Note that the collections module ABCs have separate Container and Iterable bases; neither one depends on the other.)

---

So, if you really wanted to do this without any exception handling, how could you?

Well, you have to check that at least one of the following is true:

• x has a __contains__ method.
• x has an __iter__ method.
• x has a __getitem__ method that, when called with the number 0, either returns successfully or raises IndexError.

Even if you accept that the last one can't possibly be tested without actually trying to call it with the number 0 and just assume that having __getitem__ is "close enough", how can you test for this without relying on exceptions?

You really can't. You could, e.g., iterate over dir(x), but that won't work for classes that define __contains__ dynamically, e.g., in a __getattr__ method that delegates to self.real_sequence.

And, even if you could, what happens if you have, say, a class that defines __contains__ as taking no arguments? The attribute is there, but in is still going to raise a TypeError.

And all of this is ignoring the (implementation-dependent) rules on which special methods are looked up on the object and which on the type itself. For example, in CPython 2.7:

>>> class C(object): pass
>>> c = C()
>>> c.__contains__ = lambda self, x: return True
>>> hasattr(c, '__contains__')
True
>>> c.__contains__(2)
True
>>> 2 in c
TypeError: argument of type 'C' is not iterable

Answer 2

Try except is the correct and elegant way.

First of all, whether a in b will raise exception or not depends on both a and b, not just on b alone.

The other problem is there are multiple ways that in works. Here is an example of an object which supports in, but doesn't support iteration:

>>> class EvenNumbers(object):
...     def __contains__(self, n):
...         return n % 2 == 0
...     
>>> even_numbers = EvenNumbers()
>>> 4 in even_numbers
True
>>> 5 in even_numbers
False
>>> for even_number in even_numbers:
...     pass
... 
TypeError: 'EvenNumbers' object is not iterable

And here is an example of an object which supports iteration, but doesn't define __contains__:

>>> import itertools as it
>>> even_numbers = (2*n for n in it.count())
>>> 4 in even_numbers
True
>>> even_numbers.__contains__
AttributeError: 'generator' object has no attribute '__contains__'

So to have a working LBYL implementation, you will have to take into account every possible method in which a in b can work (or not). I have only listed a couple here, there are several others. You will find your code becoming very long and ugly, and will eventually realise that try/except was the path of least resistance all along!

Answer 3

The in (and not in) operator uses __contains__() to check for membership (typically). The simplest and most elegant way to check for this is either the direct existence of the __contains__ attribute, or for the Container abstract base class:

hasattr(obj, '__contains__')

# Python 3: Container
import collections.abc
isinstance(obj, collections.abc.Container)

# Python 2: Container
import collections
isinstance(obj, collections.Container)

However, the documentation does mention:

For objects that don’t define __contains__(), the membership test first tries iteration via __iter__(), then the old sequence iteration protocol via __getitem__(), see this section in the language reference.

So, if you want to be absolutely certain in can be used without relying on a try-except block, you should use:

hasattr(obj, '__contains__') or hasattr(obj, '__iter__') or hasattr(obj, '__getitem__')

If you are expecting only container-like objects though, I would ignore __iter__() and maybe even __getitem__(), and just stick to __contains__().

Answer 4

You can check whether '__contains__' in dir(theobject), but I don't really think that try is inelegant.