True inconsistency in Python

[Ron Adam]

On Mon, 17 Nov 2003 23:13:24 -0500, "Terry Reedy" <tjreedy at udel.edu>
wrote:

>
>"Ron Adam" <radam2 at tampabay.rr.com> wrote in message
>news:ivqhrv403or6mm68arqg5793gnaaehjq8e at 4ax.com...
>> x = True
>> if x:
>> ....
>
>since the above snippert is equivalent to
>
>if True:
>...
>
>which is equivalent to
>
>...
>
>you must have meant something more imvolved.  But I am having trouble
>filling in the missing pieces.
>

Yes,  the paragraph (that you snipped) above this code snippit,
explained that you need to be able to depend on 'True' being
consistent with how the underlying operating system evaluates boolean
expressions.  If that trust is broken,  then comparisons using True
may not work.   Including "if True:".

This is so basic and simple, that you take it for granted.  And so do
many others.   

I believe the words 'True' and 'False' need to be treated the same as
the digits 1, 2, 3, ...  The values of the digits do not change.   We
depend on them not changing.

True should always evaluate to True also.  So we can depend on it as
well.  

This is my opinion,  you don't have to agree with it.


>> So I get consistent results for the language and platform I'm using
>> now and in the future.  If down the road someone decided to make
>True
>> = 3, and False = -5,  and they change the language so that any
>boolean
>> comparisons return 3 and -5 respectively,  my use of True and False
>> will still work.
>
>This strikes me as comparable to worrying about being killed by an
>asteroid.  Is there some actual historical event that makes it more
>plausible to you?

Again, it was an example of a concept.   I was trying to point out
even if the underlying values that the operating system uses to
represent true and false are changed,  having True as a constant equal
to a boolean true evaluation,  will still work.  I chose numbers that
are very unlikely to try demonstrate in an obvious way that the
concept is valid.   Sorry, if I lost you.   

Does making 'True' and 'False' constants and/or literals have any draw
backs for you?  I can only think of benefits and don't see any reason
for not doing it in this particular case.   While I admit that any
knowledgable programmer can write good programs without these being
constants or literals,   I also realize that python is becoming
popular as a teaching tool for entry level programming.  So yes,  I
believe errors using and miss using True and False will happen.

<clipped,  and opinion noted>


>
>...
>> It looks to me that 'True' in python is a combination of the boolean
>> binary logic of 1 or 0, and as an "exists" test of 0 or not 0.
>
>I do not understand this.  If you have a reference to 0, then 0
>exists.  If you do not, then the 'existence' or not of an int with
>value 0 is irrelevant.
>

if x:   is a test to see if the value 0 does not exist in x.    

Or as someone has stated to me earlier...  it is a test that something
does exist.   That something being whatever the value x represents.   

x is the number of coins I have.  ' if x:'   is a true statement if I
have some coins.    We are testing for the existence of my coins.   


>> If python had an exists operator, you could do.
>
>I think you are confusing names and objects.  You can only apply an
>operator to objects and only to objects that exist.
>

No,  I'm not confused,  and yes I am diverging here.  

>> if  x exists:
>> 'do something'
>
>Do you mean
>if bound_to_something('x'): <do something>
>?
>

Yes,  you understand.

>Normally, in the absence of error, one only uses names that one has
>defined (bound to somethingj).  So you must be worried about the
>following scenario:
>
>if a: x=1
><more code>
>if exists(x): <do something with x>
>
>In non-module script only:
>import __main__ as mm
>x = 1
>hasattr(mm, 'x') # True
>hasattr(mm, 'y') # False
>
>Anywhere: use try ... except NameError
>
>Or, don't do that (have conditionally defined name).  Instead,
>
>x=None
>if a: x = something_not_None()
><more code>
>if x != None: <do something with x>
>
>In other words, name != None is often idiom for exists('name')!
>
>> This could serve two options  also...  does the object exist?
>
>Again, Python only operates on objects that do exist.
>

Yes,  I noticed.   The reason I bring this up is in situations where
you want to initialize a variable if it has not been defined yet,  but
do not want to re initialize it if it's already been defined.

Being able to check if an object already exists could be useful.  I'll
look into the hasattr() function more,  thanks for pointing it out.

I did stray a bit on this and  I admitted so in my post.   


_Ronald Adam