(no) fast boolean evaluation ?

[Stef Mientki]

hello,

I discovered that boolean evaluation in Python is done "fast"
(as soon as the condition is ok, the rest of the expression is ignored).

Is this standard behavior or is there a compiler switch to turn it on/off ?

thanks,
Stef Mientki

[Ben Finney]

jim-on-linux <in*****@inqvis ta.comwrites:

PY help,

Using sqlite3 v3.1.3

You made this message a reply to an existing discussion, so your
message is now part of that existing discussion. Please start a new
discussion thread by composing a new message.

--
\ "True greatness is measured by how much freedom you give to |
`\ others, not by how much you can coerce others to do what you |
_o__) want." --Larry Wall |
Ben Finney

[Gabriel Genellina]

En Fri, 03 Aug 2007 11:56:07 -0300, Roel Schroeven
<rs************ ****@fastmail.f mescribió:

Paul Boddie schreef:

>On 3 Aug, 11:45, Stef Mientki <S.Mientki-nos...@mailbox. kun.nlwrote:

>>Sorry, my question missed the essential "NOT",
here is an example, that behaves different in Delphi,
(so I guess Delphi is not a real language ;-)

Delphi is based on Pascal, and from what I can recall from my
university textbook, there isn't any mandatory short-circuit
evaluation in Pascal: it's an implementation-dependent feature.
Consequently , an expression involving boolean operators in such
languages may well evaluate each term (potentially causing side-
effects) before determining the final result.

I even thought Pascal never uses short-circuit evaluation, and always
evaluates all terms. I might be wrong about that though; it's been quite
a long time since I've used Pascal.

Delphi defaults to short-circuit, but there is a compiler switch to make
it evaluate all the arguments.
But most people rely on this, and write code like:

if (MyObject <nil) and (MyObject.Event <nil) then MyObject.Event( Self);

and that would break if not short-circuited.

--
Gabriel Genellina

[Paddy]

On Aug 4, 5:33 pm, Paddy <paddy3...@goog lemail.comwrote :

On Aug 4, 4:18 pm, Paddy <paddy3...@goog lemail.comwrote :

On Aug 2, 10:47 pm, Stef Mientki <S.Mientki-nos...@mailbox. kun.nl>
wrote:

hello,

I discovered that boolean evaluation in Python is done "fast"
(as soon as the condition is ok, the rest of the expression is ignored).

Is this standard behavior or is there a compiler switch to turn it on/off ?

thanks,
Stef Mientki

The following program shows a(clumsy)? way to defeat the short-
circuiting:

def f(x):
print "f(%s)=%s" % ('x',x),
return x
def g(x):
print "g(%s)=%s" % ('x',x),
return x

print "\nShort circuit"
for i in (True, False):
for j in (True, False):
print i,j,":", f(i) and g(j)

print "\nShort circuit defeated"
for i in (True, False):
for j in (True, False):
print i,j,":", g(j) if f(i) else (g(j) and False)

The output is:

Short circuit
True True : f(x)=True g(x)=True True
True False : f(x)=True g(x)=False False
False True : f(x)=False False
False False : f(x)=False False

Short circuit defeated
True True : f(x)=True g(x)=True True
True False : f(x)=True g(x)=False False
False True : f(x)=False g(x)=True False
False False : f(x)=False g(x)=False False

- Paddy.

And here are the bits for boolean OR:

print "\n\nShort circuit: OR"
for i in (True, False):
for j in (True, False):
print i,j,":", f(i) or g(j)

print "\nShort circuit defeated: OR"
for i in (True, False):
for j in (True, False):
print i,j,":", (g(j) or True) if f(i) else g(j)

- Paddy.

Dumb!
Use & and |
Gosh That port last night was good ;-)

[Bruno Desthuilliers]

Ed Leafe a écrit :

On Aug 3, 2007, at 11:57 AM, Bruno Desthuilliers wrote:

>Sorry, I forgot to mention the language did not allow to have else & if
in the same statement. IOW :

if some_condition then
do_sometehing
else
if some_other_cond ition then
do_something_el se
else
if yet_another_con dition then
do_yet_another_ thing
else
if your_still_here then
give_up('this language is definitively brain dead')
end if
end if
end if
end if

Usually that's because the language provides a switch/case statement
construct.

Err... You may have forgotten from lack of practice, but there are
complex conditions that may not always be expressed using a switch/case...

If it does and you try to write the above code, it isn't the
language that's brain-dead! ;-)

Lats time I checked, my brain was still alive.