(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

[Neil Cerutti]

On 2007-08-03, Ed Leafe <[e-mail] ote:

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. If it does and you try to write the above
code, it isn't the language that's brain-dead! ;-)

The switch statements I'm aware of are less generally applicable
than a tower of "if { else if }* else". For example, with a
switch statement you have to dispatch on the one value for every
case.

In some languages, it's even of more limited, e.g., C, which can
switch on only integers.

--
Neil Cerutti
Next Sunday Mrs. Vinson will be soloist for the morning service. The pastor
will then speak on "It's a Terrible Experience." --Church Bulletin Blooper

[Irmen de Jong]

John Machin wrote:

>
(you_are_confus ed and/or
function_return s_bool_but_has_ _side_effects() )

That above expression should be written more explicitly like:

function_result = function_return ing_bool_but_wi th_side_effects ()

if you_are_confuse d or function_result :
do_something_ni ce()
--irmen

[Terry Reedy]

"Stef Mientki" <S.************ **@mailbox.kun. nlwrote in message
news:eb******** *************** ****@news.speed linq.nl...
| John Machin wrote:
| So now I'm left with just one question:
| for bitwise operations I should use &, |, ^
| for boolean operations I should use and, or, xor
| but after doing some test I find strange effects:
| >>A = 4
| >>B = 5
| >>A and B
| 5

>>B and A

4

| >>A & B
| 4
| >>A or B
| 4

>>B or A

5

| >>A | B
| 5
|
| So if I use the bitwise operation on integers,
| "and" changes into (bitwise) "or" and vise versa.

No, you hypnotised yourself by generalizing from insufficient data.
Repeat experiment with, for instance, 3 and 4 instead of 4 and 5. Then 3&4
= 0, 3|4 = 7.

tjr

[Frank Swarbrick]

Ian Clark wrote:

Stef Mientki 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 ?

It's called short circuit evaluation and as far as I know it's standard
in most all languages. This only occurs if a conditional evaluates to
True and the only other operators that still need to be evaluated are
'or's or the condition evaluates to False and all the other operators
are 'and's. The reason is those other operators will never change the
outcome: True or'd with any number of False's will still be True and
False and'ed to any number of Trues will still be False.

My question would be why would you *not* want this?

Pascal, and apparently Fortran, do not use short-circuit evaluation. I
remember learning this gotcha in my seventh-grade Pascal class (plus I
just googled it to make sure my memory was correct!).

Frank

[Paddy]

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.

[Paddy]

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.

[jim-on-linux]

PY help,

Using sqlite3 v3.1.3

When I create a table collumn using;

newcollum VARCHAR(35),

I get a default of 10 spaces.

No matter what I set the size to I get 10 spqces,
even using varchar(0) defaults to 10 spaces.

I would appreciae the help if someone could tell
me what I'm missing, I want to varry the column
sizes.

jim-on-linux

[Paddy]

On Aug 4, 6:51 pm, jim-on-linux <inq1...@inqvis ta.comwrote:

PY help,

Using sqlite3 v3.1.3

When I create a table collumn using;

newcollum VARCHAR(35),

I get a default of 10 spaces.

No matter what I set the size to I get 10 spqces,
even using varchar(0) defaults to 10 spaces.

I would appreciae the help if someone could tell
me what I'm missing, I want to varry the column
sizes.

jim-on-linux

Hi Jim,
You need to create a new thread for this new question so it gets
maximum visibility and so is more likely to be answered.

- Paddy.

[Carsten Haese]

On Sat, 2007-08-04 at 13:51 -0400, jim-on-linux wrote:

PY help,

Using sqlite3 v3.1.3

When I create a table collumn using;

newcollum VARCHAR(35),

I get a default of 10 spaces.

No matter what I set the size to I get 10 spqces,
even using varchar(0) defaults to 10 spaces.

I would appreciae the help if someone could tell
me what I'm missing, I want to varry the column
sizes.

What you're missing is that sqlite columns are type-less. Column type
and size are irrelevant:

>>import sqlite3
conn = sqlite3.connect (":memory")
cur = conn.cursor()
cur.execute(" create table t1 (c1 varchar(35))")

<sqlite3.Curs or object at 0xb7f6dbf0>

>>cur.executema ny("insert into t1(c1) values(?)",

.... [ ("X"*i*10,) for i in range(10) ] )

>>cur.execute(" select * from t1")

<sqlite3.Curs or object at 0xb7f6dbf0>

>>for row in cur: print row

....
(u'',)
(u'XXXXXXXXXX', )
(u'XXXXXXXXXXXX XXXXXXXX',)
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXX',)
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXX', )
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXX',)
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXX',)
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXX', )
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXX',)
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXX',)

Even though the column was created to be 35 characters wide, it'll
happily accept 100-character strings.

HTH,

--
Carsten Haese
http://informixdb.sourceforge.net

[jim-on-linux]

On Saturday 04 August 2007 14:05, Carsten Haese
wrote:

On Sat, 2007-08-04 at 13:51 -0400, jim-on-linux

wrote:

PY help,

Using sqlite3 v3.1.3

When I create a table collumn using;

newcollum VARCHAR(35),

I get a default of 10 spaces.

No matter what I set the size to I get 10
spqces, even using varchar(0) defaults to 10
spaces.

I would appreciae the help if someone could
tell me what I'm missing, I want to varry the
column sizes.

What you're missing is that sqlite columns are
type-less. Column type

and size are irrelevant:

>import sqlite3
conn = sqlite3.connect (":memory")
cur = conn.cursor()
cur.execute("c reate table t1 (c1
varchar(35)) ")

<sqlite3.Curs or object at 0xb7f6dbf0>

>cur.executeman y("insert into t1(c1)
values(?)",

... [ ("X"*i*10,) for i in range(10) ] )

>cur.execute("s elect * from t1")

<sqlite3.Curs or object at 0xb7f6dbf0>

>for row in cur: print row

...
(u'',)
(u'XXXXXXXXXX', )
(u'XXXXXXXXXXXX XXXXXXXX',)
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXX',)
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXX', )
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XX
XXXXXX',)
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XX
XXXXXXXXXXXXXX XX',)
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XX
XXXXXXXXXXXXXX XXXXXXXXXXXX',)
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XX
XXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXX',)
(u'XXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XX
XXXXXXXXXXXXXX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX XX',
)

Even though the column was created to be 35
characters wide, it'll happily accept
100-character strings.

HTH,

--
Carsten Haese
http://informixdb.sourceforge.net

Right, the data is there.
My question is framed wrong. Your answer pointed
out the flaw in the question.

Since I'm on linux, the database can be opened
with Knoda. Once opened the table collumns are
always 10 spaces so all the data is not readable
as presented. Not quite a python problem.

I can Tk a display for the data, just thought I
could save time by letting the user open the
table and read the data right from the table.

Thanks for the help.

jim-on-linux