Ronald Oussoren wrote:
> What's bothering me about the proposed semantics is that block
> statement behaves like a loop while most use cases do no looping
> whatsoever.
> Furthermore the it doesn't feel like loop either. In all three
> examples on this page I'd assume
> that the break would break out of the for loop.
I'm bothered the same way.
IMHO control constructs should be very clear. No implicit looping,
conditionals etc.
Especially since the main reason to have this whole discussion is about
resource management.
The main pattern of use I have in mind is:
resource = grab/allocate/open/whatever(...)
try:
do something possibly with the resource
except ...:
...
finally:
...
resource.release/deallocate/close/whatever()
This is linear. No looping whatsoever. And easily translated to a
simple language construct and a protocol:
class resource(object):
def __init__(self,...):
# store resource parameters
def __acquire__(self):
# whatever it takes to grab the resource
def __release__(self):
# free the resource
res = resource(...)
acquire res:
do something possibly with the resource
except ...:
...
finally:
...
The resource is automagically released at the end of the 'acquire'
block (keyword up for other proposals :-)
An alternative syntax could also be allowed:
acquire resource(...) as res:
...etc...
Then 'res' would be undefined after the 'acquire' block.
--eric
_______________________________________________
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
