[Python-Dev] PEP 340 -- loose ends

[Pierre Barbier de Reuille]

Nick Coghlan a écrit :

>>3. I'm leaning against Phillip's proposal; IMO it adds more complexity
>>for very little benefit.
> 
> 
> See my response to Phillip. I think there could be an advantage to it if it 
> means that "for l in synchronized(lock)" raises an immediate error instead of 
> silently doing the wrong thing.

First, I really think this PEP is needed for Python. But this is express 
exactly my main concern about it ! As far as I understand it, 
iterator-for-blocks and iterator-for-loops are two different beasts. 
Even if iterator-for-loops can be used within a block without damage, 
the use of iterator-for-block in a loop can lead to completely 
unpredictable result (and result really hard to find since they'll 
possibly involve race conditions or dead locks).

To try being as clear as possible, I would say the iterator-for-loops 
are simplified iterator-for-blocks. IOW, if I were to put them in a 
class inheritance hierarchy (I don't say we should put them into one ;) 
) iterator-for-block would be the base class of iterator-for-loop. Thus, 
as for-loops require an iterator-for-loop, they would raise an error if 
used with an iterator-for-block. But as blocks require an 
iterator-for-blocks they will allow iterator-for-loops too !

Cheers,

Pierre

-- 
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