[Python-ideas] x=(yield from) confusion [was:Yet another alternative name for yield-from]

[Greg Ewing]

Guido van Rossum wrote:

> We could do this based on the presence or absence of the 
> send/throw/close attributes: this would be duck typing. Or we could use 
> isinstance(it, types.GeneratorType).

I don't like the idea of switching the entire behaviour
based on a blanket generator/non-generator distinction.

Failure to duck-type is unpythonic unless there's a very
good reason for it, and I don't see any strong reason here.
Why shouldn't an iterator be able to emulate a generator
by providing all the necessary methods?

On the other hand, if we're looking at the presence of
methods, what happens if e.g. it has a throw() method
but not a send() method? Do we treat it as though the
throw() method didn't exist just because it doesn't have
the full complement of generator methods? That doesn't
seem very pythonic either.

> if EXPR produces 
> a file stream object (which has a close() method), it would not 
> consistently be closed: it would be closed if the outer generator was 
> closed before reaching the end, but not if the loop was allowed to run 
> until the end of the file.

I don't think this is a serious problem, for the following
reasons:

1. We've already more or less decided that yield-from is not
going to address the case of shared subiterators, so if anything
else would care about the file being closed unexpectedly, you
shouldn't be using yield-from on it.

2. It's well known that you can't rely on automatic closing
of files in non-refcounting implementations, so code wanting
to ensure the file is closed will need to do so explicitly
using a finally clause or something equivalent, which will
get triggered by closing the outer generator.

-- 
Greg