def __init__(self, val):
self.val = val
# Other stuff, including creating the iteratable
x = None
if isinstance(x, Continuation):
x = x.val
x = it.next()
x = Continuation(special_value)
First time post, so go gentle. :)
During a twitter conversation with @simeonvisser, an idea emerged that
he suggested I share here.
The conversation began with me complaining that I'd like a third mode of
explicit flow control in Python for-loops; the ability to repeat a loop
iteration in whole. The reason for this was that I was parsing data
where a datapoint indicated the end of a preceding sub-group, so the
datapoint was both a data structure indicator *and* data in its own
right. So I'd like to have iterated over the line once, branching into
the flow control management part of an if/else, and then again to branch
into the data management part of the same if/else.
Yes, this is unnecessary and just a convenience for parsing that I'd
like to see.
During the discussion though, a much more versatile solution presented
itself: repurposing the `continue` keyword to `continue with`, similarly
to the repurposing of `yield` with `yield from`. This would avoid
keyword bloat, but it would be explicit and intuitive to use, and would
allow a pretty interesting extension of iteration with the for-loop.
The idea is that `continue with` would allow injection of any datatype
or variable, which becomes the next iterated item. So, saying `continue
with 5` means that the next *x* in a loop structured as `for x in..`
would be 5.
This would satisfy my original, niche-y desire to re-iterate over
something, but would also more broadly allow dynamic injection of *any*
value into a for-loop iteration.
As an extension to the language, it would present new and exciting ways
to iterate infinitely by accident. It would also present new and
exciting ways for people to trip up on mutable data; one way to misuse
this is to iterate over data, modifying the data, then iterating over it
again. The intention, rather, is that the repeated iteration allows
re-iteration over unaltered data in response to a mid-iteration change
in state (i.e., in my case, parsing a token, changing parser state, and
then parsing the token again because it also carries informational content).
However, bad data hygiene has always been part of Python, because it's a
natural consequence of the pan-mutability that makes it such a great
language. So, given that the same practices that an experienced Python
dev learns to use would apply in this case, I don't think it adds
anything that an experienced dev would trip over.
As a language extension, I've never seen something like "continue with"
in another language. You can mimic it with recursive functions and
`cons`-ing the injection, but as a flow-control system for an imperative
language, nope..and Python doesn't encourage or facilitate recursion
anyway (no TCE).
I'd love thoughts on this. It's unnecessary; but then, once something's
declared turing complete you can accuse any additional feature of being
unnecessary. I feel, more to the point, that it's in keeping with the
Python philosophy and would add a novel twist to the language not seen
Twitter: @onetruecathal, @formabiolabs
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/