missing 'xor' Boolean operator
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.
More information about the Python-list