[Python-ideas] Retrying EAFP without DRY
ron3200 at gmail.com
Mon Jan 23 20:06:52 CET 2012
On Mon, 2012-01-23 at 13:34 +0900, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
> > On Mon, Jan 23, 2012 at 7:30 AM, Mike Meyer <mwm at mired.org> wrote:
> > > or wrapping a loop around the code when it wasn't really a loop.
> > You want to do the same thing more than once: that's a loop.
> That's a question of point of view. If "thing" is thought of as a
> "try" (an operation that might fail), yes, he wants to do the same
> thing a nondeterministic number of times, and in general, more than
> once: it's a loop. If "thing" is thought of as a "block" (which
> isn't a try), then the "things" done with and without exception are
> different: it's not a loop, it's a conditional.
> Looking at his example "superficially" (I intend no deprecation by
> that word, just a point of view in looking at the code), I have some
> sympathy for Mike's claim that "it's not a loop and it violates DRY."
> I "know what he means" (and I bet you do, too!) However, when I try
> to define that, even informally, I arrive at the paragraph above, and
> I end up coming down on the side that you can't consistently claim
> that "it's not a loop" *and* claim that "it violates DRY", in some
> deeper sense.
You also have to consider the size and scope of the block. Anything
more than one or two simple instructions will be difficult to achieve in
a clean way. In the case of only one or to instruction, a try block
works just fine.
For larger scopes, I think it would require some form of "UNDO_BLOCK"
opcode, so that the visited frame states can be restored before a retry
attempt is done. It would break if any c code functions visits any
frame that is outside the frames the byte code is executing in. I'd also
be concerned about memory usage and speed, because it could lead to some
very inefficient routines.
More information about the Python-ideas