[Python-ideas] x=(yield from) confusion [was:Yet another alternative name for yield-from]
greg.ewing at canterbury.ac.nz
Sun Apr 5 01:14:25 CEST 2009
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
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.
More information about the Python-ideas