145

A generator function can be defined by putting the yield keyword in the function’s body:

def gen():
    for i in range(10):
        yield i

How to define an empty generator function?

The following code doesn’t work, since Python cannot know that it is supposed to be a generator function instead of a normal function:

def empty():
    pass

I could do something like this:

def empty():
    if False:
        yield

But that would be very ugly. Is there a nicer way?

Géry Ogam
  • 6,336
  • 4
  • 38
  • 67
Konstantin Weitz
  • 6,180
  • 8
  • 26
  • 43

10 Answers10

191

You can use return once in a generator; it stops iteration without yielding anything, and thus provides an explicit alternative to letting the function run out of scope. So use yield to turn the function into a generator, but precede it with return to terminate the generator before yielding anything.

>>> def f():
...     return
...     yield
... 
>>> list(f())
[]

I'm not sure it's that much better than what you have -- it just replaces a no-op if statement with a no-op yield statement. But it is more idiomatic. Note that just using yield doesn't work.

>>> def f():
...     yield
... 
>>> list(f())
[None]

Why not just use iter(())?

This question asks specifically about an empty generator function. For that reason, I take it to be a question about the internal consistency of Python's syntax, rather than a question about the best way to create an empty iterator in general.

If question is actually about the best way to create an empty iterator, then you might agree with Zectbumo about using iter(()) instead. However, it's important to observe that iter(()) doesn't return a function! It directly returns an empty iterable. Suppose you're working with an API that expects a callable that returns an iterable each time it's called, just like an ordinary generator function. You'll have to do something like this:

def empty():
    return iter(())

(Credit should go to Unutbu for giving the first correct version of this answer.)

Now, you may find the above clearer, but I can imagine situations in which it would be less clear. Consider this example of a long list of (contrived) generator function definitions:

def zeros():
    while True:
        yield 0

def ones():
    while True:
        yield 1

...

At the end of that long list, I'd rather see something with a yield in it, like this:

def empty():
    return
    yield

or, in Python 3.3 and above (as suggested by DSM), this:

def empty():
    yield from ()

The presence of the yield keyword makes it clear at the briefest glance that this is just another generator function, exactly like all the others. It takes a bit more time to see that the iter(()) version is doing the same thing.

It's a subtle difference, but I honestly think the yield-based functions are more readable and maintainable.

See also this great answer from user3840170 that uses dis to show another reason why this approach is preferable: it emits the fewest instructions when compiled.

senderle
  • 145,869
  • 36
  • 209
  • 233
78
iter(())

You don't require a generator. C'mon guys!

Zectbumo
  • 4,128
  • 1
  • 31
  • 26
  • 4
    I definitely like this answer the best. It's quick, easy to write, fast in execution, and more appealing to me than `iter([])` for the simple fact that `()` is a constant while `[]` may instantiate a new list object in memory every time it is called. – Mumbleskates Aug 12 '15 at 03:25
  • 2
    Working back through this thread, I feel compelled to point out that if you want a true drop-in replacement for a generator function, you'd have write something like `empty = lambda: iter(())` or `def empty(): return iter(())`. – senderle Sep 24 '17 at 01:46
  • 1
    If you must have a generator then you might as well use (_ for _ in ()) as others have suggested – Zectbumo Sep 24 '17 at 11:49
  • 3
    @Zectbumo, that's still not a generator *function*. It's just a generator. A generator function returns a new generator every time it's called. – senderle Oct 18 '17 at 13:01
  • I actually did come here looking for a generator. I'm trying to append an output to the os.walk() generator. So, yes, I **do** need a generator. – ingyhere Apr 29 '20 at 17:11
  • 2
    This returns a `tuple_iterator` instead of a `generator`. If you have a case where your generator needs to return nothing, don't use this answer. – Boris Verkhovskiy Aug 30 '20 at 02:34
74

Python 3.3 (because I'm on a yield from kick, and because @senderle stole my first thought):

>>> def f():
...     yield from ()
... 
>>> list(f())
[]

But I have to admit, I'm having a hard time coming up with a use case for this for which iter([]) or (x)range(0) wouldn't work equally well.

DSM
  • 342,061
  • 65
  • 592
  • 494
  • 4
    I think this is much more readable to a novice than either `return; yield` or `if False: yield None`. – abarnert Aug 10 '14 at 03:24
  • 1
    "But I have to admit, I'm having a hard time coming up with a use case for this for which `iter([])` or `(x)range(0)` wouldn't work equally well." -> Not sure what `(x)range(0)` is, but a use case can be a method that's meant to be overridden with a full blown generator in some of the inheriting classes. For consistency purpose, you'd want even the base one, from which others inherit, to return a generator just like those overriding it. – Vedran Šego Jun 02 '19 at 10:52
26

Another option is:

(_ for _ in ())
Ben Reynwar
  • 1,547
  • 14
  • 21
18

Like @senderle said, use this:

def empty():
    return
    yield

I’m writing this answer mostly to share another justification for it.

One reason for choosing this solution above the others is that it is optimal as far as the interpreter is concerned.

>>> import dis
>>> def empty_yield_from():
...     yield from ()
... 
>>> def empty_iter():
...     return iter(())
... 
>>> def empty_return():
...     return
...     yield
...
>>> def noop():
...     pass
...
>>> dis.dis(empty_yield_from)
  2           0 LOAD_CONST               1 (())
              2 GET_YIELD_FROM_ITER
              4 LOAD_CONST               0 (None)
              6 YIELD_FROM
              8 POP_TOP
             10 LOAD_CONST               0 (None)
             12 RETURN_VALUE
>>> dis.dis(empty_iter)
  2           0 LOAD_GLOBAL              0 (iter)
              2 LOAD_CONST               1 (())
              4 CALL_FUNCTION            1
              6 RETURN_VALUE
>>> dis.dis(empty_return)
  2           0 LOAD_CONST               0 (None)
              2 RETURN_VALUE
>>> dis.dis(noop)
  2           0 LOAD_CONST               0 (None)
              2 RETURN_VALUE

As we can see, the empty_return has exactly the same bytecode as a regular empty function; the rest perform a number of other operations that don’t change the behaviour anyway. The only difference between empty_return and noop is that the former has the generator flag set:

>>> dis.show_code(noop)
Name:              noop
Filename:          <stdin>
Argument count:    0
Positional-only arguments: 0
Kw-only arguments: 0
Number of locals:  0
Stack size:        1
Flags:             OPTIMIZED, NEWLOCALS, NOFREE
Constants:
   0: None
>>> dis.show_code(empty_return)
Name:              empty_return
Filename:          <stdin>
Argument count:    0
Positional-only arguments: 0
Kw-only arguments: 0
Number of locals:  0
Stack size:        1
Flags:             OPTIMIZED, NEWLOCALS, GENERATOR, NOFREE
Constants:
   0: None

The above disassembly is outdated as of CPython 3.11, but empty_return still comes out on top, with only two more opcodes (four bytes) than a no-op function:

>>> dis.dis(empty_yield_from)
  1           0 RETURN_GENERATOR
              2 POP_TOP
              4 RESUME                   0

  2           6 LOAD_CONST               1 (())
              8 GET_YIELD_FROM_ITER
             10 LOAD_CONST               0 (None)
        >>   12 SEND                     3 (to 20)
             14 YIELD_VALUE
             16 RESUME                   2
             18 JUMP_BACKWARD_NO_INTERRUPT     4 (to 12)
        >>   20 POP_TOP
             22 LOAD_CONST               0 (None)
             24 RETURN_VALUE
>>> dis.dis(empty_iter)
  1           0 RESUME                   0

  2           2 LOAD_GLOBAL              1 (NULL + iter)
             14 LOAD_CONST               1 (())
             16 PRECALL                  1
             20 CALL                     1
             30 RETURN_VALUE
>>> dis.dis(empty_return)
  1           0 RETURN_GENERATOR
              2 POP_TOP
              4 RESUME                   0

  2           6 LOAD_CONST               0 (None)
              8 RETURN_VALUE
>>> dis.dis(noop)
  1           0 RESUME                   0

  2           2 LOAD_CONST               0 (None)
              4 RETURN_VALUE

Of course, the strength of this argument is very dependent on the particular implementation of Python in use; a sufficiently smart alternative interpreter may notice that the other operations amount to nothing useful and optimise them out. However, even if such optimisations are present, they require the interpreter to spend time performing them and to safeguard against optimisation assumptions being broken, like the iter identifier at global scope being rebound to something else (even though that would most likely indicate a bug if it actually happened). In the case of empty_return there is simply nothing to optimise, as bytecode generation stops after a return statement, so even the relatively naïve CPython will not waste time on any spurious operations.

user3840170
  • 26,597
  • 4
  • 30
  • 62
  • Oh, nice. Could you add the results for `yield from ()` as well? (See [DSM](https://stackoverflow.com/a/13243920/577088)'s answer.) – senderle Oct 15 '20 at 22:40
  • 1
    Great answer. It's a bit sad that ``yield from ()`` generated code is less optimized, because it source looks the most intuitive and clean.. – Dmitriy Sintsov Jan 26 '21 at 08:58
4

Must it be a generator function? If not, how about

def empty():
    return iter(())

or simpler and more direct

empty = ().__iter__
Zectbumo
  • 4,128
  • 1
  • 31
  • 26
unutbu
  • 842,883
  • 184
  • 1,785
  • 1,677
  • In some contexts `partial(iter, ())` (`from functools import partial`) or `lambda: iter(())` might be more preferable. – mtraceur Sep 03 '22 at 21:19
2

The "standard" way to make an empty iterator appears to be iter([]). I suggested to make [] the default argument to iter(); this was rejected with good arguments, see http://bugs.python.org/issue25215 - Jurjen

Jurjen Bos
  • 49
  • 1
2

I want to give a class based example since we haven't had any suggested yet. This is a callable iterator that generates no items. I believe this is a straightforward and descriptive way to solve the issue.

class EmptyGenerator:
    def __iter__(self):
        return self
    def __next__(self):
        raise StopIteration

>>> list(EmptyGenerator())
[]
Zectbumo
  • 4,128
  • 1
  • 31
  • 26
  • Can you add some explanation why/how this works to solve the OP's issue? – SherylHohman Sep 06 '20 at 07:17
  • Please don't post only code as answer, but also provide an explanation what your code does and how it solves the problem of the question. Answers with an explanation are usually more helpful and of better quality, and are more likely to attract upvotes. – SherylHohman Sep 06 '20 at 07:53
2

Nobody has mentioned it yet, but calling the built-in function zip with no arguments returns an empty iterator:

>>> it = zip()
>>> next(it)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration
Géry Ogam
  • 6,336
  • 4
  • 38
  • 67
1
generator = (item for item in [])