True

D

Daniel Klein

In Python 2.2 I use to have

true = (1 == 1)
false = not true

This was at the recommendation of someone on this list some time ago.
The reason (if I remember correctly) was that setting

true = 1
false = 0

were not true booleans.

Now the expression (1 == 1) returns 'True', and caused a bug in my
code. So my question is what is the proper method for setting booleans
in 2.3?

Really confused,

Daniel Klein
 
L

Lee Harr

In Python 2.2 I use to have

true = (1 == 1)
false = not true

This was at the recommendation of someone on this list some time ago.
The reason (if I remember correctly) was that setting

true = 1
false = 0

were not true booleans.

Now the expression (1 == 1) returns 'True', and caused a bug in my

Actually, it returns True, not 'True'
code. So my question is what is the proper method for setting booleans
in 2.3?

Really confused,

True and False are now built in to 2.3
Python 2.3 (#1, Aug 1 2003, 15:18:54)
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more information.['ArithmeticError', 'AssertionError', 'AttributeError', 'DeprecationWarning',
'EOFError', 'Ellipsis', 'EnvironmentError', 'Exception',

'False', .snip. 'True', .snip.

'type', 'unichr', 'unicode', 'vars', 'xrange', 'zip']



but I think if you had an up-to-date 2.2 they should have been there too...



python2.2
Python 2.2.3 (#1, Jun 9 2003, 18:01:50)
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more information.['ArithmeticError', 'AssertionError', 'AttributeError', 'DeprecationWarning',
'EOFError', 'Ellipsis', 'EnvironmentError', 'Exception',

'False', .snip. 'True', .snip.

'super', 'tuple', 'type', 'unichr', 'unicode', 'vars', 'xrange', 'zip']




What error are you getting? How are you using true and false?
I know the developers were very careful to not cause any compatibilty
problems with the addition of booleans.
 
J

John Roth

Daniel Klein said:
In Python 2.2 I use to have

true = (1 == 1)
false = not true

This was at the recommendation of someone on this list some time ago.
The reason (if I remember correctly) was that setting

true = 1
false = 0

were not true booleans.

There were no true booleans in 2.2 and earlier. Whoever recommended
that didn't know what he was talking about. There was no difference.
Now the expression (1 == 1) returns 'True', and caused a bug in my
code. So my question is what is the proper method for setting booleans
in 2.3?

I presume what broke your code was depending on the return from
either str() or repr(), or the % operator. That was, unfortunately, one
of the incompatibilites between 2.2 and 2.3.

In 2.3, Boolean is a subtype of Int, and has two values: True and False.
Both of these are built in constants, so just use them. That's what they're
for. For most purposes, the are the same as 1 and 0, except for what they
return from str() and repr(), and how they get formatted with %.

John Roth
 
?

=?iso-8859-1?q?Fran=E7ois_Pinard?=

[Daniel Klein]
So my question is what is the proper method for setting booleans in 2.3?

Hi, Daniel.

In 2.3, you do not need to set booleans, `True' and `False' are just there.

However, if you have a need to write portably against many versions, you
might try something like:

try:
True
except NameError:
False, True = range(2)

in modules where you need to use `True' or `False'.
 
J

John Roth

Andrew Dalke said:
Daniel Klein:

John Roth

Indeed, there were no true booleans in Python, but there were
actual PyTrue and PyFalse objects at the C level. Doing the "1 == 1"
trick would expose that implementation choice to Python.

This was rarely used. The only place I know of is in the win32 code,
where a COM API can take a boolean or an integer function. The
win32 interface checks if the value is PyTrue/PyFalse,

Here's relevant links
http://mail.python.org/pipermail/python-list/1999-November/015260.html
http://mailman.pythonpros.com/pipermail/pycom-dev/1999q1/000106.html

So, are you saying that this would have returned -1, rather than 1?

John Roth
 
A

Andrew Dalke

John Roth:
So, are you saying that this would have returned -1, rather than 1?

No, and I don't know how you thought I suggested it. If PyTrue returned
-1 before then "True = (1==1)" would not provide the right compatibility
between different Python versions and so would not be an appropriate
suggestion at all.

You must have misread the text from the second URL
http://mailman.pythonpros.com/pipermail/pycom-dev/1999q1/000106.html
in it, Mark Hammond said:
The only thing that I can see changing is the literal value of the
boolean field - currently, the conversion from VT_BOOL to integer will
result in 0 or -1. PyTrue is 1

The boolean returned from COM is -1. PyTrue is (and was) 1.

Andrew
(e-mail address removed)
 
D

Daniel Klein

Actually, it returns True, not 'True'

In this case, it _did_ return a literal string of 'True' cuz I was
using str(true) and str(false). That was the nature of the buglet.
Before str(true) would return return '1' and str(false) would return
'0'. Sorry that I didn't include this bit of information in the
original post :-(

Dan
 
D

Daniel Klein

[Daniel Klein]
So my question is what is the proper method for setting booleans in 2.3?

Hi, Daniel.

In 2.3, you do not need to set booleans, `True' and `False' are just there.

However, if you have a need to write portably against many versions, you
might try something like:

try:
True
except NameError:
False, True = range(2)

in modules where you need to use `True' or `False'.

Thanks François. I don't need to support multiple versions. I simply
changed the code from:

true = (1 == 1)

to

true = 1

and presto, no more bug :)

Dan
 
D

Daniel Klein

For the sake of being pedantic, I believe your code still does have a
bug. You bug is that you rely on the "str()" of a boolean value
returning a specific string. Your code should probably check the bool
and create your own string rather than relying on this behaviour
remaining unchanged forever.

I'm not really taking a str() on a boolean value anymore; it's being
taken on an integer value. Are you saying that...

true = 1
str(true) # this should always return '1' now and forever more

....could cause problems in the future?

The reason I'm taking a str() value is cuz it is being sent over a
socket to a non-python server process, where it is converted back to a
boolean.

Make sense now?

Dan
 
D

Daniel Klein

The reason I'm taking a str() value is cuz it is being sent over a
socket to a non-python server process, where it is converted back to a
boolean.

In that case, you'd be better off converting using your own routine
rather than relying on a particular behaviour of str() for this test.
Basically, do something like

def boolean2String(boolVal):
return { False : '1', True : '0' } [ not boolVal ]

and save yourself any further future pain...

Thanks Peter, that will do the trick. Just wondering though why you
chose to code the opposite values and not as

def boolean2String(boolVal):
return {True:'1', False:'0'}[boolVal]

Dan
 
T

Terry Reedy

def boolean2String(boolVal):
return { False : '1', True : '0' } [ not boolVal ]
Thanks Peter, that will do the trick. Just wondering though why you
chose to code the opposite values and not as

def boolean2String(boolVal):
return {True:'1', False:'0'}[boolVal]

Your function requires the arg to be 0/1 (True/False). Peter's
function works for *any* input that can be 'not'ed.

TJR
 
M

Martin v. =?iso-8859-15?q?L=F6wis?=

Peter Hansen said:
As Skip said... but it should have had a comment anyway, since it
wasn't clear. You could also consider using "not not boolVal" if
you want to make the code _slightly_ (IMHO) more readable, and slightly
slower, but I think one still needs a comment explaining it. :-(

I find

def boolean2str(val):
if val:
return '1'
else:
return '0'

both more readable, and twice as fast. It doesn't need to create a
dictionary each time, and it does not to perform a dictionary lookup.
If you prefer compactness, use

def boolean2str(val, results=('1', '0')):
return results[not val]

Regards,
Martin
 
T

Terry Reedy

Martin v. Löwis said:
If you prefer compactness, use

def boolean2str(val, results=('1', '0')):
return results[not val]

-or, more safely (no default arg to accidently overwrite)-

def boolean2str(val):
return val and '1' or '0'

But one might want the flexibility of intentionally replacing the
results default, as in

print boolean2str(somevalue, ('T', 'F'))

Terry J. Reedy
 
P

Paul Watson

John Roth said:
There were no true booleans in 2.2 and earlier. Whoever recommended
that didn't know what he was talking about. There was no difference.


I presume what broke your code was depending on the return from
either str() or repr(), or the % operator. That was, unfortunately, one
of the incompatibilites between 2.2 and 2.3.

In 2.3, Boolean is a subtype of Int, and has two values: True and False.
Both of these are built in constants, so just use them. That's what they're
for. For most purposes, the are the same as 1 and 0, except for what they
return from str() and repr(), and how they get formatted with %.

John Roth

Then, what is the best way to write boolean operations for Python 2.1 so
that it will be as 2.3+ ready as possible?

Should we just use 0 and 1?

Until the vendor of the tool we are using delivers a more recent version of
Python with the product, we must produce 2.1 compatible code.

Thanks.
 
D

David Eppstein

"Paul Watson said:
Then, what is the best way to write boolean operations for Python 2.1 so
that it will be as 2.3+ ready as possible?

I've been including the following at the start of some of my code:

if 'True' not in globals():
globals()['True'] = not None
globals()['False'] = not True

My hope is that setting up True and False in this convoluted way will
allow it to continue to work in some future version where assignment to
builtins is disallowed.
 
A

Andrew Bennetts

Paul Watson said:
Then, what is the best way to write boolean operations for Python 2.1 so
that it will be as 2.3+ ready as possible?

I've been including the following at the start of some of my code:

if 'True' not in globals():
globals()['True'] = not None
globals()['False'] = not True

Why not simply:

try:
True
except NameError:
True = (1 == 1) # or not None, if you prefer
False = not True

Or were you trying to change the __builtins__ by using globals()?

-Andrew.
 
D

Duncan Booth

Then, what is the best way to write boolean operations for Python 2.1 so
that it will be as 2.3+ ready as possible?

I've been including the following at the start of some of my code:

if 'True' not in globals():
globals()['True'] = not None
globals()['False'] = not True

My hope is that setting up True and False in this convoluted way will
allow it to continue to work in some future version where assignment to
builtins is disallowed.

Since True will never be in globals unless you assign it there, you might
as well just drop the if statement altogether. Also I fail to see what
benefit you gain from the contorted assignment into the globals dictionary.
Why not just write:

True = not None
False = not True

It has the same effect overall.

If you want to avoid hiding the builtin True and False, then use try..catch
to detect them.
 
P

Peter Otten

Andrew said:
Paul Watson said:
Then, what is the best way to write boolean operations for Python 2.1
so that it will be as 2.3+ ready as possible?

I've been including the following at the start of some of my code:

if 'True' not in globals():
globals()['True'] = not None
globals()['False'] = not True

Why not simply:

try:
True
except NameError:
True = (1 == 1) # or not None, if you prefer
False = not True

Or were you trying to change the __builtins__ by using globals()?

-Andrew.

I suppose David tries to avoid a syntax error raised by the assignment

True = somethingElse

in a future version of Python. Therefore he has "hidden" the builtins to be
assigned from the compiler by turning them into strings.

Peter
 
D

David Eppstein

Peter Otten said:
I suppose David tries to avoid a syntax error raised by the assignment

True = somethingElse

in a future version of Python. Therefore he has "hidden" the builtins to be
assigned from the compiler by turning them into strings.

Yes, exactly.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,598
Members
45,158
Latest member
Vinay_Kumar Nevatia
Top