Guido van Rossum wrote:
> 1. I still can't decide on keyword vs. no keyword, but if we're going
> to have a keyword, I haven't seen a better proposal than block. So
> it's either block or nothing. I'll sleep on this. Feel free to start
> an all-out flame war on this in c.l.py. ;-)
I quite like 'block', but can live with no keyword (since it then becomes a
practical equivalent to user-defined statements).
> 2. No else clause; the use case is really weak and there are too many
> possible semantics. It's not clear whether to generalize from
> for/else, or if/else, or what else.
Agreed. The order I posted my list of semantic options was the order I thought
of them, but I ended up agreeing with the votes Aahz posted.
> 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.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4