Op 2005-09-09, Terry Hancock schreef <[EMAIL PROTECTED]>:
> On Thursday 08 September 2005 04:30 am, Paul Rubin wrote:
>> Terry Hancock <[EMAIL PROTECTED]> writes:
>> > > Not the same at all. It evaluates both the true and false results,
>> > > which may have side effects.
>> >
>> > If you are dep
On Thursday 08 September 2005 04:30 am, Paul Rubin wrote:
> Terry Hancock <[EMAIL PROTECTED]> writes:
> > > Not the same at all. It evaluates both the true and false results,
> > > which may have side effects.
> >
> > If you are depending on that kind of nit-picking behavior,
> > you have a serio
Op 2005-09-08, Duncan Booth schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Which is why I don't understand the resistance against introducing
>> such a beast.
>
> The idea has already been discussed to death. Read PEP 308 to see what was
> proposed, discussed, and why the PEP was eventua
Antoon Pardon wrote:
> Which is why I don't understand the resistance against introducing
> such a beast.
The idea has already been discussed to death. Read PEP 308 to see what was
proposed, discussed, and why the PEP was eventually rejected:
http://www.python.org/peps/pep-0308.html:
> Status:
Op 2005-09-07, Terry Reedy schreef <[EMAIL PROTECTED]>:
>
> "Kay Schluehr" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> No, as I explained it is not a ternary operator and it can't easily be
>> implemented using a Python function efficiently because Python does not
>> support l
Terry Hancock <[EMAIL PROTECTED]> writes:
> > Not the same at all. It evaluates both the true and false results,
> > which may have side effects.
>
> If you are depending on that kind of nit-picking behavior,
> you have a serious design flaw, a bug waiting to bite you,
> and code which shouldn't
On Wed, 7 Sep 2005 17:53:46 -0500, Terry Hancock <[EMAIL PROTECTED]> wrote:
>On Wednesday 07 September 2005 02:44 pm, Paul Rubin wrote:
>> Terry Hancock <[EMAIL PROTECTED]> writes:
>> > def ternary(condition, true_result, false_result):
>> >if condition:
>> >return true_result
>> >
Kay Schluehr wrote:
> Terry Reedy wrote:
>> *If* bool(result_expression_i) == True for all i, (except maybe last
>> default expression), which is true for some actual use cases, then the
>> following expression evaluates to the result corresponding to the first
>> 'true' condition (if there is one
On Wednesday 07 September 2005 02:44 pm, Paul Rubin wrote:
> Terry Hancock <[EMAIL PROTECTED]> writes:
> > def ternary(condition, true_result, false_result):
> > if condition:
> > return true_result
> > else:
> > return false_result
> >
> > Almost as good, and you d
Terry Reedy wrote:
> "Kay Schluehr" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > No, as I explained it is not a ternary operator and it can't easily be
> > implemented using a Python function efficiently because Python does not
> > support lazy evaluation.
>
> By *carefully* us
Terry Hancock <[EMAIL PROTECTED]> writes:
> def ternary(condition, true_result, false_result):
> if condition:
> return true_result
> else:
> return false_result
>
> Almost as good, and you don't have to talk curmudgeons into providing
> it for you.
Not the
"Kay Schluehr" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> No, as I explained it is not a ternary operator and it can't easily be
> implemented using a Python function efficiently because Python does not
> support lazy evaluation.
By *carefully* using the flow-control operators
Terry Hancock wrote:
> On Wednesday 07 September 2005 05:29 am, Kay Schluehr wrote:
> > Instead of pushing statements into expressions one can try to do it the
> > other way round and model expressions with the functionality of
> > statements.
>
> > Alternative syntax proposals:
> >
> > (a) (COND
On Wednesday 07 September 2005 05:29 am, Kay Schluehr wrote:
> Instead of pushing statements into expressions one can try to do it the
> other way round and model expressions with the functionality of
> statements.
> Alternative syntax proposals:
>
> (a) (COND1,EXPR1) || (COND2,EXPR2)
> (b)
One of the main reasons Pythons anonymous function lambda is considered
to be "broken" is Pythons disability to put statements into expressions
and support full functionality. Many attempts to improve lambdas syntax
had also been attempts to break the expression/statement distinction in
one or the
15 matches
Mail list logo
