[Python-Dev] PEP 340 -- concept clarification

[Guido van Rossum]

[Raymond Hettinger]
> I just made a first reading of the PEP and want to clarify my
> understanding of how it fits with existing concepts.

Thanks! Now is about the right time -- all the loose ends are being
solidified (in my mind any way).

> Is it correct to say that "continue" parallel's its current meaning and
> returns control upwards (?outwards) to the block iterator that called
> it?

I have a hard time using directions as metaphors (maybe because on
some hardware, stacks grow down) unless you mean "up in the source
code" which doesn't make a lot of sense either in this context.

But yes, continue does what you expect it to do in a loop.

Of course, in a resource allocation block, continue and break are
pretty much the same (just as they are in any loop that you know has
only one iteration).

> Likewise, is it correct that "yield" is anti-parallel to the current
> meaning?  Inside a generator, it returns control upwards to the caller.
> But inside a block-iterator, it pushes control downwards (?inwards) to
> the block it controls.

I have a hard time visualizing the difference. They feel the same to
me, and the implementation (from the generator's POV) is identical:
yield suspends the current frame, returning to the previous frame from
the call to next() or __next__(), and the suspended frame can be
resumed by calling next() / __next__() again.

> Is the distinction between block iterators and generators similar to the
> Gang-of-Four's distinction between external and internal iterators?

I looked it up in the book (p. 260), and I think generators have a
duality to them that makes the distinction useless, or at least
relative to your POV. With a classic for-loop driven by a generator,
the author of the for-loop thinks of it as an external iterator -- you
ask for the next item using the (implicit) call to next(). But the
author of the generator thinks of it as an internal iterator -- the
for loop resumes only when the generator feels like it.

> Are there some good use cases that do not involve resource locking?
> IIRC, that same use case was listed a prime motivating example for
> decorators (i.e. @syncronized).  TOOWTDI suggests that a single use case
> should not be used to justify multiple, orthogonal control structures.

Decorators don't need @synchronized as a motivating use case; there
are plenty of other use cases.

Anyway, @synchronized was mostly a demonstration toy; whole method
calls are rarely the right granularity of locking. (BTW in the latest
version of PEP 340 I've renamed synchronized to locking; many people
complained about the strange Javaesque term.)

Look at the examples in the PEP (version 1.16) for more use cases.

> It would be great if we could point to some code in the standard library
> or in a major Python application that would be better (cleaner, faster,
> or clearer) if re-written using blocks and block-iterators.  I've
> scanned through the code base looking for some places to apply the idea
> and have come up empty handed.  This could mean that I've not yet
> grasped the essence of what makes the idea useful or it may have other
> implications such as apps needing to be designed from the ground-up with
> block iterators in mind.

I presume you mentally discarded the resource allocation use cases
where the try/finally statement was the outermost statement in the
function body, since those would be helped by @synchronized; but look
more closely at Queue, and you'll find that the two such methods use
different locks!

Also the use case for closing a file upon leaving a block, while
clearly a resource allocation use case, doesn't work well with a
decorator.

I just came across another use case that is fairly common in the
standard library: redirecting sys.stdout. This is just a beauty (in
fact I'll add it to the PEP):

def saving_stdout(f):
    save_stdout = sys.stdout
    try:
        sys.stdout = f
        yield
    finally:
        sys.stdout = save_stdout

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)