missing 'xor' Boolean operator

Luis Zarrabeitia kyrie at uh.cu
Fri Jul 17 16:19:51 CEST 2009


On Friday 17 July 2009 07:06:26 am Jean-Michel Pichavant wrote:
>
> I was saying that using boolean operators with object instead of boolean
> values is error prone, cause no language behaves he same way,

I don't know of many languages that actively promote the duck typing concept, 
are as highly dynamic as python, have the "metaclass" concept, treats almost 
all language concepts as first class citizens (including functions and 
classes), and so on. And don't get me started on assignment (which I consider 
very natural, by the way, but apparently most of the popular languages have 
pretty unnatural assignments).

It is error prone if you are expecting the result to be a bool instead of just
behaving like one (it is certainly unexpected, but you shouldn't be expecting 
to get an instance of certain class anyway, for most of python's operations). 
And it is confusing if you are reading the "int(inputVar) or 25" line and 
have no idea of what it means (but once you know it, it becomes very 
readable, almost plain english).

> and all 
> behaviors are conventions difficult to figure out without diving deeply
> into the documentation (or being explained as it happened to me).

That happens with many new concepts. Welcome to python, I guess... if you are 
willing to shake some of your expectations from previous programming 
languages, you will enjoy it. My [little] experience teaching python tells me 
that "duck typing", "non-enforced encapsulation" and "everything is an 
object" are the hardest to accept for the C# folk at my faculty, but once 
past it, they (the few of them who don't leave the course after that) really 
enjoy the language.

> I think the initialization trick is an error, because I don't want
> foo(0) to set daysInAdvance to 25. I'll want it to set the attribute to
> 0, cause 0 is a valid integer. 0 is a valid integer content, None
> wouldn't be a valid integer content.

Well, that wouldn't be a problem with "or", but with the programmer.

The exact same behaviour could be obtained with

if int(inputValue) == 0:
    inputValue = 25

and no "or" involved.

However, using only

inputValue = inputValue or 25

could have been an error if you only wanted 25 in case inputValue is None.

(the "or trick" implies certain trust in that the object you have in hand has 
a reasonable definition of truth value).

-- 
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie



More information about the Python-list mailing list