RetroSearch Browse

Wed Apr 27 13:44:49 CEST 2005 · https://mail.python.org/pipermail/python-dev/2005-April/053037.html

Greg Ewing wrote:
> Nick Coghlan wrote:
> 
>> def template():
>>   # pre_part_1
>>   yield None
>>   # post_part_1
>>   yield None
>>   # pre_part_2
>>   yield None
>>   # post_part_2
>>   yield None
>>   # pre_part_3
>>   yield None
>>   # post_part_3
>>
>> def user():
>>   block = template()
>>   with block:
>>     # do_part_1
>>   with block:
>>     # do_part_2
>>   with block:
>>     # do_part_3
> 
> 
> That's an interesting idea, but do you have any use cases
> in mind?

I was trying to address a use case which looked something like:

    do_begin()
    # code
    if some_condition:
       do_pre()
       # more code
       do_post()
    do_end()

It's actually doable with a non-looping block statement, but I have yet to come 
up with a version which isn't as ugly as hell.

> I worry that it will be too restrictive to be really useful.
> Without the ability for the iterator to control which blocks
> get executed and when, you wouldn't be able to implement
> something like a case statement, for example.

We can't write a case statement with a looping block statement either, since 
we're restricted to executing the same suite whenever we encounter a yield 
expression. At least the non-looping version offers some hope, since each yield 
can result in the execution of different code.

For me, the main sticking point is that we *already* have a looping construct to 
drain an iterator - a 'for' loop. The more different the block statement's 
semantics are from a regular loop, the more powerful I think the combination 
will be. Whereas if the block statement is just a for loop with slightly tweaked 
exception handling semantics, then the potential combinations will be far less 
interesting.

My current thinking is that we would be better served by a block construct that 
guaranteed it would call __next__() on entry and on exit, but did not drain the 
generator (e.g. by supplying appropriate __enter__() and __exit__() methods on 
generators for a PEP 310 style block statement, or __enter__(), __except__() and 
__no_except__() for the enhanced version posted elsewhere in this rambling 
discussion).

However, I'm currently scattering my thoughts across half-a-dozen different 
conversation threads. So I'm going to stop doing that, and try to put it all 
into one coherent post :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2005-April/053037.html below:

[Python-Dev] Re: anonymous blocks