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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
_______________________________________________
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
