[MERGE] Improve tests for the behaviour of Tree.iter_changes for missing paths that are only present in one tree, and fix found bugs. (Robert Collins)

[Stephen J. Turnbull]

Robert Collins writes:

 > I don't think GeneratorExit is something ever raised by user code is it?
 > I mean, if I write to the byte-code, sure.

Probably not, if you insist on doing it via raise.  However,
generators have a special .close() method that raises it.  I'm not
sure if .close() does anything else; if not, raising GeneratorExit
might be the preferred way for a function to exit a higher level
generator.

 > StopIteration is more interesting, but in fact - it is exceptional for
 > an iterator to end, because you don't know when that is going to be, but
 > control has returned to you. Using a sentinel may well be cleaner, but -
 > that, like generator exit, entirely hidden from [most] user code.

Sure, but my point is that the exception mechanism is being used as a
first-class control mechanism in the implementation, by somebody whose
taste in these matters I respect greatly.

I tend to think of exceptions as being *structurally* exceptional, in
that they can bypass multiple levels of control structure, returning
to some outermost structure.  As opposed to dynamically exceptional in
the sense of "rare" or "unexpected."