[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/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
