Quoting Jean-Michel Pichavant <jeanmic...@sequans.com>: > Emile van Sebille wrote: > > On 7/16/2009 7:04 AM Unknown said... > >> On 2009-07-16, Emile van Sebille <em...@fenx.com> wrote: > >>> daysInAdvance = int(inputVar) or 25 > >> > >> I don't get it. That doesn't work right when inputVar == "0". > >> > > Aah, but you didn't get to define right. :) For that particular > > example 0 is not a valid response. > > When I was talking about such error prone form of boolean operations, I > didn't expect to be right so quickly :p
What do you mean by being "right so quickly", and "error prone" in this context? I would also ask "Unknown" why he believes that "int(intputVar) or 25" doesn't work right when inputVar == "0". The only false value that int() may return is zero, so the "or 25" clause is there only for that case. I can't see then how you think that is an error. > I'm not sure it makes sens anyway. I > mean, I could easily argue that the number 0 is something. In the end I > wonder if I shouldn't just acknowledge the python mechanism Then look it another way. The "Empty/Nothing" is just standard practice, there is nothing in python that forces you to be "false" if you are empty, or true otherwise. Instead, answer this: why do you need a /boolean/ value? Is there any case where you need to be certain that the object's type is 'bool'? If you think the answer is "yes", you may want to get more familiar with the "duck typing" concept. (That doesn't mean that there are no legitimate cases where duck typing is inappropriate, but that there are many cases where people, specially if they come from statically typed languages, may believe that it is inappropriate when it isn't). In the python world, one should care more about how an object /behaves/ than from what clase it came. If something quacks like a duck, then assume that it is a duck, at least for the quacking part. Most python objects carry a truth value. Sometimes it feels natural (None is "false", boolean True and False are "true" and "false", empty containers are expected to be false, 0 and '' are "false"). Sometimes, it is everything but natural, but that's a problem with the object's implementation (datetime.time comes to mind). So, you shouldn't care if you have a bool instance - it should be enough that it behaves like a bool (though, if you need a bool, you can always construct one). The "True or False" expression could return Giraffes, as long as Giraffes behave like the bool "True" in boolean context. If you care about the class of the result, you can ask for its truth value, and if you don't care about it, you can just ignore it, and use it as you would use a bool. And then, if you can return any object as long as it behaves properly, what would be better to return? A new bool? Why not new Giraffe, if they will have the same behaviour? Guido chose to return the a value that will say more about the result of the operation than just a boolean. It acts as a boolean - if you don't need anything else, treat it as such -, but it will be, whenever is possible, one of the objects in the sequence, in case you need more info. > without > trying to find any intuitive/natural/obvious logic in it, knowing that > sometimes the Truth lies far away from the Evidence. Don't do that. Many of python's decisions are very well thought. You may disagree with them, as I do with some, but they are rarely taken lightly. And this is one that I find very agreeable and in line with the rest of python's philosophy. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list