Michael Hudson wrote:
> I _like_ the explanation of 'and' and 'or' as they are now. They are
> basically control flow constructs -- and have to be to get
> short-circuiting to work -- and adding a coercion to bool at the end
> seems to add complexity, not reduce it (on some levels, anyway).
Agreed. However, Raymond and Brett seem to have some ideas about optimising
the normal comparison bytecode without changing the semantics, which would be
good.
>>P.S. Simplifying "and" and "or" may create a need to introduce a
>>conditional operator but that is a discussion for another day.
>
>
> ... which was in the past, I thought.
C'mon, PEP 308 was fun for everybody };)
The ease of writing buggy code when trying to fake a conditional operator
using and/or does seem to cause the question to keep coming up despite the
fate of PEP 308, though. But the only way I can ever see a conditional
operator happening is if Guido simply selects which of the top 4** PEP 308
solutions he likes best and says "make it so!".
Cheers,
Nick.
** I say top 4, because there was daylight between the votes for the first 4
choices and all of the other PEP 308 options. And many of the pros and cons of
those 4 choices are so subjective that I wouldn't expect further discussion to
significantly change anyone's opinion.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
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
