Neil Schemenauer wrote:

...

A variation on this with somewhat different semantics swaps the keywords:

in EXPR for VAR: BLOCK

Looks weird to my eyes.

Probably makes perfect sense if you're Dutch, though. :-) -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing@canterbury.ac.nz +--------------------------------------+

[Nicolas Fleury]

I would prefer something that would be understandable for a newbie's eyes, even if it fits more with common usage than with the real semantics behind it. For example a Boost-like keyword like:

scoped EXPR as VAR: BLOCK

Definitely not. In too many languages, a "scope" is a new namespace, and that's exactly what a block (by whichever name) is *not*. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:

[Nicolas Fleury]

...

scoped EXPR as VAR: BLOCK

Definitely not. In too many languages, a "scope" is a new namespace, and that's exactly what a block (by whichever name) is *not*.

Humm... what about "context"? context EXPR as VAR: BLOCK I may answer the question myself, but is an alternative syntax without an indentation conceivable? (yes, even since the implicit block could be run multiple times). Because in that case, a keyword like "block" would not look right. It seems to me that in most RAII cases, the block could end at the end of the current block and that's fine, and over-indentation can be avoided. However, I realize that the indentation makes more sense in the context of Python and removes some magic that would be natural for a C++ programmer used to presence of stack... Ok, I answer my question, but "context" still sounds nicer to me than "block";) Regards, Nicolas

Far too close to the "for" loop, IMHO. I read that, I'd have to remind myself every time, "now, which one is it that can receive values passed back in: for ... in, or in ... for?"

Whoa! Read the PEP closely. Passing a value back to the iterator (using "continue EXPR") is supported both in the for-loop and in the block-statement; it's new syntax so there's no backwards compatibility issue. The real difference is that when a for-loop is exited through a break, return or exception, the iterator is left untouched; but when the same happens in a block-statement, the iterator's __exit__ or __error__ method is called (I haven't decided what to call it).

Another possibility just occurred to me. How about "using"?

Blah. I'm beginning to like block just fine. With using, the choice of word for the generator name becomes iffy IMO; and it almost sounds like it's a simple renaming: "using X as Y" could mean "Y = X". -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Robin Munn wrote: [snip]

Another possibility just occurred to me. How about "using"?

~ using EXPR as VAR: ~ BLOCK

Examples from PEP 340: ========== def synchronized(lock): ... using synchronized(myLock): ... ===== (+0) def opening(filename, mode="r"): ... using opening("/etc/passwd") as f: ... ===== (+1) def auto_retry(n=3, exc=Exception): ... using auto_retry(3, IOError): ... ===== (+1) def synchronized_opening(lock, filename, mode="r"): ... using synchronized_opening("/etc/passwd", myLock) as f: ... ===== (+1) A.R.

Nick Coghlan a écrit :

Python offers two variants on the basic iterative loop.

"for NAME from EXPR:" enforces finalisation of the iterator. At loop completion, a well-behaved iterator is always completely exhausted. This form supports block management operations, that ensure timely release of resources such as locks or file handles. If the values being iterated over are not required, then the statement may be simplified to "for EXPR:".

"for NAME in EXPR:" skips the finalisation step. At loop completion, a well-behaved iterator may still contain additional values. This form allows an iterator to be consumed in stages.

Regardless of whether you like the above or not, I think the PEP's proposed use of 'as' is incorrect - it looks like the variable should be referring to the expression being iterated over, rather than the values returned from the iterator.

Cheers, Nick.

Well, I would go a step further and keep only the for-loop syntax, mainly because I don't understand why there is two syntax for things that's so close we can merge them ! You can simply states that the for-loop call the "__error__" method of the object if available without invalidating any other property of the new for-loop (ie. as defined in the PEP 340). 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 ! 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. 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

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

Nick Coghlan wrote:

Then, in Py3K, finalisation could simply become the default for loop behaviour. However, the '__finalise__' flag would result in some impressive code bloat, as any for loop would need to expand to:

itr = iter(EXPR1) if getattr(itr, "__finalise__", False): # Finalised semantics # I'm trying to channel Guido here. # This would really look like whatever the PEP 340 block statement # semantics end up being val = arg = None ret = broke = False while True: try: VAR1 = next(itr, arg) except StopIteration: BLOCK2 break try: val = arg = None ret = False BLOCK1 except Exception, val: itr.__error__(val) if ret: try: itr.__error__(StopIteration()) except StopIteration: pass return val

The problem is that BLOCK2 is executed within the while loop (the same problem I had with a fix I offered), which may contain a break for breaking out of a higher-level loop construct. Here's one that works as you intended (though perhaps I'm being a bit to paranoid about the __error__ attribute)... val = arg = None ret = ex_block_2 = False while True: try: VAR1 = next(itr, arg) except StopIteration: ex_block_2 = True break try: val = arg = None ret = False BLOCK1 except Exception, val: if hasattr(itr, '__error__): itr.__error__(val) if ret: try: if hasattr(itr, '__error__'): itr.__error__(StopIteration()) except StopIteration: pass return val if ex_block_2: BLOCK2

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)

Indeed, I also mentioned this on Wednesday. - Josiah

On Fri, Apr 29, 2005, Nick Coghlan wrote:

If you want to emphasise the similarity, the following syntax and explanation is something that occurred to me during lunch today:

We don't want to emphasize the similarity.

Python offers two variants on the basic iterative loop.

"for NAME from EXPR:" enforces finalisation of the iterator. At loop completion, a well-behaved iterator is always completely exhausted. This form supports block management operations, that ensure timely release of resources such as locks or file handles. If the values being iterated over are not required, then the statement may be simplified to "for EXPR:".

"for NAME in EXPR:" skips the finalisation step. At loop completion, a well-behaved iterator may still contain additional values. This form allows an iterator to be consumed in stages.

-1 -- the Zen of Python implies that we should be able to tell which construct we're using at the beginning of the line. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It's 106 miles to Chicago. We have a full tank of gas, a half-pack of cigarettes, it's dark, and we're wearing sunglasses." "Hit it."

[Phillip J. Eby]

Although I'd personally prefer a no-keyword approach:

synchronized(self): with_file("foo") as f: # etc.

I'd like that too, but it was shot down at least once. Maybe we can resurrect it? opening("foo") as f: # etc. is just a beauty! -- --Guido van Rossum (home page: http://www.python.org/~guido/)

I agree, but does this then work:

x = opening("foo") ...stuff... x as f: # etc

? And if not, why not? And if yes, what happens if "stuff" raises an exception?

Forget it -- the above is probably addressed by the PEP and doesn't really depend on whether there's a kw or not.

At 10:42 AM 4/29/05 -0700, Aahz wrote:

On Fri, Apr 29, 2005, Guido van Rossum wrote:

...

[Phillip J. Eby]

...

Although I'd personally prefer a no-keyword approach:

synchronized(self): with_file("foo") as f: # etc.

I'd like that too, but it was shot down at least once. Maybe we can resurrect it?

opening("foo") as f: # etc.

I'm still -1 for the same reason I mentioned earlier: function calls spanning multiple lines are moderately common in Python code, and it's hard to distinguish these cases because multi-line calls usually get indented like blocks.

But the indentation of a multi-line call doesn't start with a colon. Or are you saying you're concerned about things like: opening( blah, blah, foo, wah=flah ) as fidgety, widgety, foo: sping() Which is quite ugly, to be sure, but then I don't see where adding an extra keyword helps.

At 12:05 PM 4/29/05 -0700, Aahz wrote:

On Fri, Apr 29, 2005, Phillip J. Eby wrote:

...

At 10:42 AM 4/29/05 -0700, Aahz wrote:

...

On Fri, Apr 29, 2005, Guido van Rossum wrote:

...

[Phillip J. Eby]

...

Although I'd personally prefer a no-keyword approach:

synchronized(self): with_file("foo") as f: # etc.

I'd like that too, but it was shot down at least once. Maybe we can resurrect it?

opening("foo") as f: # etc.

I'm still -1 for the same reason I mentioned earlier: function calls spanning multiple lines are moderately common in Python code, and it's hard to distinguish these cases because multi-line calls usually get indented like blocks.

But the indentation of a multi-line call doesn't start with a colon.

Neither does the un-keyworded block. It starts with a colon on the end of the previous line. I thought part of the point of Python was to minimize reliance on punctuation, especially where it's not clearly visible?

Actually, I've just realized that I was misled by your argument into thinking that the possibility of confusing a multi-line call and a block of this sort is a problem. It's not, because template blocks can be viewed as multi-line calls that just happen to include a block of code as one of the arguments. So, mistaking one for the other when you're just skimming the code and not looking at things like "as" or the ":", is really not important. In the second place, the most important cue to understanding the behavior of a template block is the template function itself; the bare syntax gives it the most prominence. Blocks like 'synchronized(self):' should be instantly comprehensible to Java programmers, for example, and 'retry(3):' is also pretty self-explanatory. And so far, template function names and signatures have been quite brief as well.

[Phillip]

...

In the second place, the most important cue to understanding the behavior of a template block is the template function itself; the bare syntax gives it the most prominence. Blocks like 'synchronized(self):' should be instantly comprehensible to Java programmers, for example, and 'retry(3):' is also pretty self-explanatory. And so far, template function names and signatures have been quite brief as well.

[Aahz]

This works IMO IFF Python is regarded as a language with user-defined syntactical structures. Guido has historically disagreed strongly with that philosophy; until and unless he reverses his opinion, this is precisely why the non-keyword version will continue to receive -1 from me. (As it happens, I agree with Guido, so if Guido wants to change, I'll probably argue until I see good reason. ;-)

Actually, I think this is a nice way to have my cake and eat it too: on the one hand, there still isn't any user-defined syntax, because the keyword-less block syntax is still fixed by the compiler. On the other hand, people are free to *think* of it as introducing syntax if it helps them understand the code better. Just as you can think of each distinct @decorator as a separate piece of syntax that modifies a function/method definition. And just as you can think of a function call as a user-defined language extension. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

[Phillip]

By the way, I notice PEP 340 has two outstanding items with my name on them; let me see if I can help eliminate one real quick.

Tracebacks: it occurs to me that I may have unintentionally given the impression that I need to pass in an arbitrary traceback, when in fact I only need to pass in the current sys.exc_info().

I've updated the PEP (tying a couple of loose ends and making the promised change to the new API); I've decided to change the signature of __exit__() to be a triple matching the return value of sys.exc_info(), IOW the same as the "signature" of the raise-statement. There are still a few loose ends left, including the alternative API that you've proposed (which I'm not super keen on, to be sure, but which is still open for consideration). -- --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:

[Phillip J. Eby]

...

Although I'd personally prefer a no-keyword approach:

synchronized(self): with_file("foo") as f: # etc.

I'd like that too, but it was shot down at least once. Maybe we can resurrect it?

opening("foo") as f: # etc.

is just a beauty!

+1 Certainly my favorite because it's direct and easy on the eyes. Second would be:: in opening("foo") as f: # etc. because I can see Aahz's point about introducing the block with a keyword instead of relying on the ":" punctuation and subsequent indentation of the block for skimming code. -Shane Holloway