Ron Adam <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > > Ron Adam <[EMAIL PROTECTED]> wrote: > > > >> There's also the possibility to use conditional looping based on the > value returned from the generator. > >> > >> do VAR from EXPR if VAR==CONST: > >> BLOCK > >> > >> This is a bit verbose, but it reads well. :-) > > > > > > > > Reading well or not, this is not really an option for the same reasons > > why... > > > > for VAR in EXPR1 if EXPR2: > > or > > for VAR in EXPR1 while EXPR2: > > > > are not options. Keep it simple. > > > > Yes, so just "do [VAR from] EXPR1:"
Regardless of the 'finalization' syntax, I'm talking about the fact that including extra 'if EXPR' or 'while EXPR' is not going to be an option. > >> 3. Do-loops: An generator based loop with finalization: This > could be both single and multiple pass. The difference is determined by > weather or not the generator used loops the yield statement or not. > > > > > > Offering only generator-based finalization loops is, as I understand it, > > not an option. > > It could also include classes with __exit__ methods which are really > just more complex generators when used this way. > > But isn't this what PEP340 *already* proposes? Or am I missing a subtle > distinction here. It is, in fact, what PEP 340 already proposes. Let us take a step back for a moment and realize that this entire discussion is going around in circles. >From what I understand, we all agree: 1. There should be some mechanism X which signals that an indented suite is a 'block statement'. Such blocks are described and finalized as per PEP 340 (or whatever derivative gets accepted). 2. Standard for/while loops should not be finalized in a timely fashion, because testing for the proper methods would necessarily slow down large amounts of current Python, so should be left to the garbage collector. 3. A note as to the additional overhead of finalized blocks should be mentioned in the source code of the finalization implementation, and a note on their performace characteristics may or may not need to be listed in the language reference. What there is still discussion over: 4. What the syntax should be. 5. Whether or not it loops. 6. Method names. I find the answers to 4,5,6 to be a matter of opinion, and like many, I have my own. However, I do not feel strongly enough about 4,5,6 to argue about my opinion (I've been attempting to re-state where the conversation went for the last 2 weeks, as I have managed to read each and every email about the subject at hand *ick*). - Josiah _______________________________________________ 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
