[Python-Dev] PEP 340 - possible new name for block-statement

[Pierre Barbier de Reuille]

Nick Coghlan a écrit :
> Pierre Barbier de Reuille wrote:
> 
>> One main reason is a common error could be (using the synchronised 
>> iterator introduced in the PEP):
>>
>> for l in synchronised(mylock):
>>   do_something()
>>
>> It will compile, run, never raise any error but the lock will be 
>> acquired and never released !
> 
> 
> It's better than that. With the code above, CPython is actually likely 
> to release the lock when the loop exits. Change the code to the below to 
> ensure the lock doesn't get released:
> 
>   sync = synchronised(mylock):
>   for l in sync:
>       do_something()
> 

Well indeed, but this will be an implementation-dependant behaviour ...

>> Then, I think there is no use case of a generator with __error__ in 
>> the for-loop as it is now. So, IMO, it is error-prone and useless to 
>> have two different syntaxes for such things.
> 
> 
[...]
> 
> The major danger I see is that you could then write a generator 
> containing a yield inside a try/finally, _without_ applying the 
> finalisation decorator. Leading to exactly the problem described above - 
> the lock (or whatever) is never cleaned up, because the generator is not 
> flagged for finalisation. In this scenario, even destruction of the 
> generator object won't help.


Mmmmh ... why introduce a new flag ? Can't you just test the presence of 
the "__error__" method ? This would lift your problem wouldn't it ?

> 
> Cheers,
> Nick.
> 
> P.S. I think PEP 340's proposed for loop semantics are currently 
> incorrect, as BLOCK2 is unreachable. It should look more like the 
> non-finalised semantics above (with BLOCK2 before the break in the 
> except clause)
> 

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77    fax   : (33) 4 67 61 56 68