On Sun, 13 Mar 2005, Greg Ewing wrote: > Brian Sabbey wrote: >> I prefer re-using the 'for' loop for this purpose because it allows the >> problem to be solved in a general way by re-using a structure with which >> most users are already familiar, and uses generators, which are easier to >> use in this case than defining a class with __exit__, __enter__, etc. > > But this is an abuse of both the for-loop and the generator. > It's using a for-loop for something that does not loop and > is never intended to loop, and it's using yield to do > something other than producing a value for consumption. > > I'd rather see a new mechanism altogether for this very > different use case. The problem with creating a new mechanism is that sometimes you will want to loop. For example, reading a bunch of items from a shared resource, modifying them, and sending them back. A new, non-looping mechanism will not be adequate for this because it cannot loop, and a 'for' loop will not be adequate for the same reason it is not adequate now: it can't automatically unlock the resource at the end of the loop. I was looking for a single mechanism to handle all of these cases, but I can see why you and most people would not be so keen on the idea of abusing (I prefer "expanding the uses of") 'for' loops this way. -Brian
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4