(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

[Gabriel Genellina]

En Thu, 02 Aug 2007 18:47:49 -0300, Stef Mientki
<S.**************@mailbox.kun.nlescribió:

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 ?

The exact behavior is defined in the Language Reference
<http://docs.python.org/ref/Booleans.html>

"The expression x and y first evaluates x; if x is false, its value is
returned; otherwise, y is evaluated and the resulting value is returned.
The expression x or y first evaluates x; if x is true, its value is
returned; otherwise, y is evaluated and the resulting value is returned.
Note that neither and nor or restrict the value and type they return to
False and True, but rather return the last evaluated argument. This is
sometimes useful, e.g., if s is a string that should be replaced by a
default value if it is empty, the expression s or 'foo' yields the desired
value."

Tutorial section 5.7 say the same thing in a colloquial way.

--
Gabriel Genellina

[Ian Clark]

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 ?

thanks,
Stef Mientki

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?

Ian

[Evan Klitzke]

On 8/2/07, Stef Mientki <S.**************@mailbox.kun.nlwrote:

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 ?

This is standard behavior in every language I've ever encountered. If
you are evaluating an and/or with side effects and you need both side
effects to occur, you can trivially write functions implementing this
behavior, e.g.

def a():
print 'foo'
def b():
print 'bar'
def my_and(lh, rh):
return a and b

Then my_and(a(), b()) will evaluate both a and b and print both foo
and bar even though a() is False.

--
Evan Klitzke <ev**@yelp.com>

[John Machin]

On Aug 3, 8:55 am, Ian Clark <[e-mail]:

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 ?

thanks,
Stef Mientki

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?

Why? Perhaps under some compound condition like this:

(you_are_confused and/or
function_returns_bool_but_has__side_effects())

[John Machin]

On Aug 3, 9:19 am, "Evan Klitzke" <[e-mail]:

On 8/2/07, Stef Mientki <[e-mail]:

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 ?

This is standard behavior in every language I've ever encountered. If
you are evaluating an and/or with side effects and you need both side
effects to occur, you can trivially write functions implementing this
behavior, e.g.

If each operand is of type bool (or, more generally,
isinstance(operand, int) is true), you could trivially use the & and |
operators.

[Joshua J. Kugler]

On Thursday 02 August 2007 15:19, Evan Klitzke wrote:

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

This is standard behavior in every language I've ever encountered.

Then you've never programmed in VB (at least 6, don't know if .net still
does this). Nested IF statements. AAAAAAAAAAAAAAAAAAAACK! Thankfully, I
program mostly in Python these days. Haven't touched VB in years. Maybe
you should have said:

"This is standard behavior in every real programming language."

There, that should start a flame war. :)

j

--
Joshua Kugler
Lead System Admin -- Senior Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ Â*ID 0xDB26D7CE

[Laurent Pointal]

Stef Mientki a écrit :

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 ?

As it was replied, its standard behavior and cannot be modified.

IMHO, if you really need all your expressions to be evaluated, the clean
(most readable) way may be:

a = <first_expression which must be evaluated>
b = <second_expression(x,y,z) which must be evaluated>
if a and b :
...

A+

Laurent.

[Bruno Desthuilliers]

Joshua J. Kugler a écrit :

On Thursday 02 August 2007 15:19, Evan Klitzke wrote:

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

This is standard behavior in every language I've ever encountered.

Then you've never programmed in VB (at least 6, don't know if .net still
does this). Nested IF statements. AAAAAAAAAAAAAAAAAAAACK!

I do remember an even brain-deadiest language that not only didn't
short-circuit boolean operators but also didn't have an "elif" statement...

[Stef Mientki]

John Machin wrote:

On Aug 3, 8:55 am, Ian Clark <[e-mail]:

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

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?

Why? Perhaps under some compound condition like this:

(you_are_confused and/or
function_returns_bool_but_has__side_effects())

Thanks guys,
Yes this is exactly what's going wrong ...

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 ;-)

<Python>
def Some_Function (const):
print 'Ive been here', const
return True

A = True

if A and Some_Function (4 ):
print 'I knew it was True'
else:
print 'I''ll never print this'
</Python>

<Output>
Ive been here 4
I knew it was True
</Output

I was expected that the function would not be called,
because A is True.

And I agree with Laurent that it should be better to write a clean code,
so it doesn't matter whether you write in Python or in Delphi.

Gabriel: you pointed me to this page:
The exact behavior is defined in the Language Reference <http://docs.python.org/ref/Booleans.html>

<quote>
or_test ::= and_test | or_test "or" and_test
</quote

Can you imagine, while I'm not a programmer, just a human,
that I don't understand one bit of this line.

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

>>A & B

4

>>A or B

4

>>A | B

5

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

Is there some way to prevent / detect these kind of errors
( as I'm building a micro-controller simulator in Python,
I need both logical and bitwise operators very frequently).

cheers,
Stef Mientki

[Laurent Pointal]

Stef Mientki a écrit :

<Python>
def Some_Function (const):
print 'Ive been here', const
return True

A = True

if A and Some_Function (4 ):
print 'I knew it was True'
else:
print 'I''ll never print this'
</Python>

<Output>
Ive been here 4
I knew it was True
</Output

I was expected that the function would not be called,
because A is True.

When using the *and* operator, the short-circuit evaluation is done if A
is False (no need to know the other operand, the result cannot be True).
But if A is True, the compiler must evaluate the second parameter to
know the expression result.

[note: for the or operator, the short circuit is done if first operand
is True]

A+

Laurent.

PS. See http://en.wikipedia.org/wiki/Truth_table or google for boolean
logic tables.

[Diez B. Roggisch]

Stef Mientki schrieb:

John Machin wrote:

>On Aug 3, 8:55 am, Ian Clark <[e-mail]:

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

Why? Perhaps under some compound condition like this:

(you_are_confused and/or
function_returns_bool_but_has__side_effects())

Thanks guys,
Yes this is exactly what's going wrong ...

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 ;-)

<Python>
def Some_Function (const):
print 'Ive been here', const
return True

A = True

if A and Some_Function (4 ):
print 'I knew it was True'
else:
print 'I''ll never print this'
</Python>

<Output>
Ive been here 4
I knew it was True
</Output

I was expected that the function would not be called,
because A is True.

And I agree with Laurent that it should be better to write a clean code,
so it doesn't matter whether you write in Python or in Delphi.

Gabriel: you pointed me to this page:
The exact behavior is defined in the Language Reference
<http://docs.python.org/ref/Booleans.html>

<quote>
or_test ::= and_test | or_test "or" and_test
</quote

Can you imagine, while I'm not a programmer, just a human,
that I don't understand one bit of this line.

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

>>A & B

4

>>A or B

4

>>A | B

5

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

No!!! Don't think that!

Choose different numbers, and you will see that.

The semantics for the and/or operators are spelled out like this
(extra-verbose):
def and(a, b):
if bool(a) == True:
if bool(b) == True
return b # because it holds True == bool(b)
return a # because it holds Fals == bool(a)

def or(a, b):
if bool(a) == True:
return a
return b
This could be considered unfortunate because it relies on the implicit
boolean nature of certain values like "", 0, 1, {} and so forth - but
it's the way it is.

However, this has _nothing_ to do with the bitwise operations! The work
on the bits of integers, and because 5 and 4 are bitwise 0b101 and
0x100, the

5 & 4 -4 == 0b100

and

5 | 4 -5 == 0x101

That's all!

If you need non-circuiting and/or, write functions and and or:

def and_(a, b):
return a and b

def or_(a, b):
return a or b

That will ensure argument evaluation.

Diez

[Stef Mientki]

Laurent Pointal wrote:

Stef Mientki a écrit :

><Python>
def Some_Function (const):
print 'Ive been here', const
return True

A = True

if A and Some_Function (4 ):
print 'I knew it was True'
else:
print 'I''ll never print this'
</Python>

<Output>
Ive been here 4
I knew it was True
</Output

I was expected that the function would not be called,
because A is True.

When using the *and* operator, the short-circuit evaluation is done if A
is False (no need to know the other operand, the result cannot be True).
But if A is True, the compiler must evaluate the second parameter to
know the expression result.

Sorry you're completely right,
and indeed I must have something very stupid !!

thanks very much
Stef Mientki

[Bruno Desthuilliers]

Stef Mientki a écrit :
(snip)

Gabriel: you pointed me to this page:
The exact behavior is defined in the Language Reference
<http://docs.python.org/ref/Booleans.html>

<quote>
or_test ::= and_test | or_test "or" and_test
</quote

Can you imagine, while I'm not a programmer, just a human,
that I don't understand one bit of this line.

This is a variant[2] of the BNF notation[1] for languages grammar.
You'll find such notation in almost any programming language.

[1] http://en.wikipedia.org/wiki/Backus-Naur_form
[2] http://docs.python.org/ref/notation.html

So now I'm left with just one question:
for bitwise operations I should use &, |, ^

yes.

for boolean operations I should use and, or, xor

yes.

but after doing some test I find strange effects:

>>A = 4
>>B = 5
>>A and B

5

>>A & B

4

>>A or B

4

>>A | B

5

Nothing strange here. You now know how boolean operators works. Bitwise
operators are something different (while still related). Represent
yourself ints as bit fields, ie (restricting ourselves to 4-bits words
for the example):

0 =0000
1 =0001
2 =0010
3 =0011
4 =0100
5 =0101
6 =0110
7 =0111
8 =1000

(etc)

The bitwise operators works this way:

1/ the & operator compares each bit of it's operands, and for each
returns '1' if both bits are '1', else '0'. So you have:

A & B =4 & 5 =0100 & 0101 =0100 =4

0100
& 0101
----
0100

2/ the | operator compares each bit of it's operands, and for each
returns '1' if one of the bits is '1', else '0'. So you have:

A | B =4 | 5 =0100 | 0101 =0101 =5

0100
| 0101
----
0101
HTH

[Steven D'Aprano]

On Fri, 03 Aug 2007 10:20:59 +0200, Bruno Desthuilliers wrote:

Joshua J. Kugler a écrit :

>On Thursday 02 August 2007 15:19, Evan Klitzke wrote:

>>>I discovered that boolean evaluation in Python is done "fast"
(as soon as the condition is ok, the rest of the expression is ignored).
This is standard behavior in every language I've ever encountered.

Then you've never programmed in VB (at least 6, don't know if .net still
does this). Nested IF statements. AAAAAAAAAAAAAAAAAAAACK!

I do remember an even brain-deadiest language that not only didn't
short-circuit boolean operators but also didn't have an "elif" statement...

Is it a secret?

I'm a little perplexed at why you say a language without "elif" is a good
sign of brain-death in a programming language. I understand that, given
the parsing rules of Python, it is better to use elif than the equivalent:

if condition:
pass
else:
if another_condition:
pass
But that's specific to the syntax of the language. You could, if you
choose, design a language where elif was unnecessary:

if condition:
pass
else if another_condition:
pass

What advantage is there to "elif", apart from it needing three fewer
characters to type?

--
Steven.

[Neil Cerutti]

On 2007-08-03, Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:

But that's specific to the syntax of the language. You could,
if you choose, design a language where elif was unnecessary:

if condition:
pass
else if another_condition:
pass

What advantage is there to "elif", apart from it needing three
fewer characters to type?

It's a great boon to the authors of auto-indenting text editors.

--
Neil Cerutti

[Paul Boddie]

On 3 Aug, 11:45, Stef Mientki <[e-mail]:

>
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.

Paul

[Roel Schroeven]

Paul Boddie schreef:

On 3 Aug, 11:45, Stef Mientki <[e-mail]:

>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.

--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven

[Bruno Desthuilliers]

Steven D'Aprano a écrit :

On Fri, 03 Aug 2007 10:20:59 +0200, Bruno Desthuilliers wrote:

>Joshua J. Kugler a écrit :

>>On Thursday 02 August 2007 15:19, Evan Klitzke wrote:
I discovered that boolean evaluation in Python is done "fast"
(as soon as the condition is ok, the rest of the expression is ignored).
This is standard behavior in every language I've ever encountered.
Then you've never programmed in VB (at least 6, don't know if .net still
does this). Nested IF statements. AAAAAAAAAAAAAAAAAAAACK!

I do remember an even brain-deadiest language that not only didn't
short-circuit boolean operators but also didn't have an "elif" statement...

Is it a secret?

I'm a little perplexed at why you say a language without "elif" is a good
sign of brain-death in a programming language. I understand that, given
the parsing rules of Python, it is better to use elif than the equivalent:

if condition:
pass
else:
if another_condition:
pass
But that's specific to the syntax of the language. You could, if you
choose, design a language where elif was unnecessary:

if condition:
pass
else if another_condition:
pass

What advantage is there to "elif", apart from it needing three fewer
characters to type?

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_condition then
do_something_else
else
if yet_another_condition 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

[Ed Leafe]

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_condition then
do_something_else
else
if yet_another_condition 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! ;-)

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

[Neil Cerutti]

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

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_condition then
do_something_else
else
if yet_another_condition 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_confused and/or
function_returns_bool_but_has__side_effects())

That above expression should be written more explicitly like:

function_result = function_returning_bool_but_with_side_effects()

if you_are_confused or function_result:
do_something_nice()
--irmen

[Terry Reedy]

"Stef Mientki" <S.**************@mailbox.kun.nlwrote in message
news:eb***************************@news.speedlinq. 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 <[e-mail]>
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 <[e-mail]:

On Aug 2, 10:47 pm, Stef Mientki <[e-mail]>
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 <[e-mail]:

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.Cursor object at 0xb7f6dbf0>

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

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

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

<sqlite3.Cursor object at 0xb7f6dbf0>

>>for row in cur: print row

....
(u'',)
(u'XXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',)

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("create table t1 (c1
varchar(35))")

<sqlite3.Cursor object at 0xb7f6dbf0>

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

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

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

<sqlite3.Cursor object at 0xb7f6dbf0>

>for row in cur: print row

...
(u'',)
(u'XXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',)
(u'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' ,
)

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

[Ben Finney]

jim-on-linux <in*****@inqvista.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.fmescribió:

Paul Boddie schreef:

>On 3 Aug, 11:45, Stef Mientki <[e-mail]:

>>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 <[e-mail]:

On Aug 4, 4:18 pm, Paddy <[e-mail]:

On Aug 2, 10:47 pm, Stef Mientki <[e-mail]>
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_condition then
do_something_else
else
if yet_another_condition 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.