Boolean value of generators

[John Nagle]

On 10/14/2010 2:21 PM, Cameron Simpson wrote:
> On 14Oct2010 14:13, Tim Chase<python.list at tim.thechases.com>  wrote:
> | On 10/14/10 12:53, Paul Rubin wrote:
> |>Carl Banks<pavlovevidence at gmail.com>   writes:
> |>>In general, the only way to test if a generator is empty is to try to
> |>>consume an item.  (It's possible to write an iterator that consumes an
> |>>item and caches it to be returned on the next next(), and whose
> |>>boolean status indicates if there's an item left. ...)
> |>
> |>I remember thinking that Python would be better off if all generators
> |>automatically cached an item, so you could test for emptiness, look
> |>ahead at the next item without consuming it, etc.  This might have been
> |>a good change to make in Python 3.0 (it would have broken compatibility
> |>with 2.x) but it's too late now.
> |
> | Generators can do dangerous things...I'm not sure I'd *want* to have
> | Python implicitly cache generators without an explicit wrapper to
> | request it: [... damaging counter example ...]
>
> +1 to this. Speaking for myself, I would _not_ want a generator to
> commence execution unless I overtly iterate over it.

    This issue has come up before in I/O systems,
where someone may want to test for EOF.  In Pascal, there was
a predicate to test "files" for EOF.  This didn't work out well for
interactive or network input, since testing for EOF had to block until
input appeared.

    The general solution today is to return an EOF token and/or fail
a read at EOF.  Reading ahead leads to deadlocks.

    The same logic applies to generators.  A generator may be getting
data from some source that can block.  So an EOF test would lead
to trouble.

				John Nagle