0

Using the built-in assert statement, is there a good, Pythonic way of checking emptiness in an iterable? I have seen:

but I'm looking for a solution using assertions. The following looks to work, but I am unsure whether I'm missing some important possible exception:

a = [1, 2, 3]
b = []

assert a, 'a is empty'
assert b, 'b is empty'

Which raises this AssertionError:

Traceback (most recent call last):
  File "<ipython-input-9-185714f6eb3c>", line 5, in <module>
    assert b, 'b is empty'
AssertionError: b is empty
Community
  • 1
  • 1
blacksite
  • 12,086
  • 10
  • 64
  • 109
  • 2
    Neither of those things actually tests whether any *iterable* is empty or not. Lists belong to a particular class of iterables (*sequences*) that are false-y if empty. Empty *iterators*, on the other hand, are not false-y (`bool(iter([]))` evaluates to `True`). Why don't you want to use the existing answers? As to the second part of your question - `assert` statements are optimised out in certain conditions, and you can choose errors other than `AssertionError` if you're raising them yourself. – jonrsharpe Dec 22 '16 at 16:51
  • Useful reading: http://stackoverflow.com/q/9884132/3001761 – jonrsharpe Dec 22 '16 at 16:58

2 Answers2

4

Remember not to confuse a container (think lists, sets, tuples, dictionaries, whatever) with an iterable (anything that can come up with a new state). The only way to check whether an iterable is "empty" is to try to iterate over it and find out if it does not produce at least one new state. You are free to interpret that as the iterable being "empty".

Something like this

def test_thing_is_empty(self):  # We are in a unittest.Testcase
    foo = iter([])  # Or any other iterable thing
    try:
        item = next(foo)
    except StopIteration:
        pass  # This is what should happen
    else:
        self.fail("Expected foo to be empty, got %s" % (item, ))

Also remember that an iterable is technically never truly "empty". It is allowed, though discouraged, for an iterable to throw a StopIteration sometimes and all of the sudden start producing new elements if tried again.

Therefore there is no way to assert this. You have to try and see if you fail. If you do fail, the only true knowledge is that the iterable did not produce a new state right now (for whatever reason). If you get an item back, the iterable just produced a unique, precious snowflake that may never be reproducable again (think reading from network socket somewhere down the stack).

user2722968
  • 13,636
  • 2
  • 46
  • 67
  • 1
    The only downside of this is that the iterable might be empty *after* you've decided it's not empty! – jonrsharpe Dec 22 '16 at 17:04
  • There is no way to prevent this. An iterable may produce precious snowflakes as it goes along, change it's environment (think reading from a socket) and so on. The only way to use an iterable is to poke it. Updated the answer to make this clear – user2722968 Dec 22 '16 at 17:06
  • True enough, it depends precisely what the OP's use case is. – jonrsharpe Dec 22 '16 at 17:08
  • Yes. If OP wants to peek into the iterable, he can put the item into a tuple and itertools.chain((item, ), foo) to get an iterable that will produce that item again. He has to chain the iterator (foo), not the original object, because the object is free to produce another iterable that behaves differently. – user2722968 Dec 22 '16 at 17:15
  • 1
    "It is allowed, though discouraged, for an iterable to throw a StopIteration sometimes and all of the sudden start producing new elements if tried again." Is there some source or further reading for this? The iterator protocol is closely related to `for x in iterable:`, and I would expect such iterator to not work properly? – Rawler Apr 14 '23 at 09:35
  • @Rawler See [here](https://docs.python.org/3/library/stdtypes.html#iterator.__next__). – user2722968 Apr 14 '23 at 10:48
  • @user2722968 But the linked docs say _broken_, not discouraged: "Once an iterator’s `__next__()` method raises `StopIteration`, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken." – alexh May 01 '23 at 19:56
  • @alexh Yes, my point is that it is "technically possible" for an iterator to resume iterating after raising `StopIterator`. However, users of that iterator will likely not consider this scenario, which is why those iterators are "broken by default". It is definitely not Ok to expect users of your Iterator to expect that behavior. However, it is possible, so in circumstances where you control both the Iterator and the consumer of that iIterator, it may be viable. – user2722968 May 01 '23 at 22:00
-2

How about:

assert len(a), "a is empty"

It has the same effect as assert a, ... for list, dict and set objects but you may find that it looks clearer/more maintainable.

Neither assert a, ... nor assert len(a), ... is guaranteed to work for arbitrary iterables, though you may find the latter preferable simply because it throws an exception for iterables that have no __len__, rather than potentially letting the assertion pass with a false-positive. It looks like there is no completely general solution (i.e. a solution for which you couldn't construct an iterable that would defeat it).

jez
  • 14,867
  • 5
  • 37
  • 64
  • 2
    This doesn't work for arbitrary iterables, many of which do not have a length. – jonrsharpe Dec 22 '16 at 17:01
  • @jonrsharpe true, though it's not 100% clear to me that the OP necessarily requires a solution for arbitrary iterables, rather than just lists. – jez Dec 22 '16 at 17:43