On Wed, Nov 12, 2014 at 01:25:15AM +0000, Danny Yoo wrote: > Just to note; not all programming languages do it this way. Python is > fairly permissive in what it allows to be "truthy". See: > https://plus.google.com/+ShriramKrishnamurthi/posts/4qvvKYC1R8Y for a brief > survey of what many other programming languages do. > > It can be confusing and bug-prone as heck.
I strongly disagree, especially since Python has an excellent model for deciding truthiness by default: something versus nothing. Python's treatment of true/false values matches the standard Python philosophy of duck-typing. Rather than require a fixed type of object, say a duck, Python generally allows you to use anything which behaves sufficiently duck-like for your purposes. All Python objects quack like bools, and truthiness is a fundamental property of all Python objects. Unlike some languages, which choose confusing and arbitrary sets of values that count as truthy or falsey, Python encourages a simple distinction, something versus nothing. Values which represent some kind of "nothing" are falsey: - numeric zeroes, e.g. 0, 0.0, 0j, Decimal(0) - empty containers, e.g. [], (), {}, set(), frozenset() - empty strings, e.g. "", u"" - None Values with represent something are truthy: - non-zero numbers - non-empty containers - non-empty strings - arbitrary objects > For myself, I usually want as restrictive an approach as possible with > respect to what things are considered "truthy". If I'm in a boolean > context, I will explicitly make the expression being tested be either True > or False, and that's it. Do you duck-type other kinds of values, or do you insist on explicitly forcing everything to be a single kind of object? Do you write "len(list(sequence))", or just "len(sequence)"? If you allow len() to duck-type its argument, why not allow duck-typing bools? > That way, I know I won't get into shaky waters. > I program in multiple languages: I don't want to spend brain power > remembering yet another a truth table about truth. It's your choice to program in multiple languages. Presumably you get some benefit from that. The cost of using different languages is that they are different: they have different semantics, syntax, libraries, they use different idioms, require you to write different code. If you don't like that, don't write code in different languages. Do you complain that it is "confusing and bug-prone as heck" that the same operation might be spelled any of these ways? len(x) laenge(x) length(x) x.len() x.len size(x) sizeof(x) x len len x x:length() All languages makes choices. Complaining that a specific choice is hard to use, inconsistent with the rest of the language, confusing or bug-prone is okay. Complaining that different languages have different semantics is, well, silly. Different programming languages are different, that's why they're different languages and not all FORTRAN. Anyone who writes: if bool(x): ... in Python instead of just "if x" is just exposing their own confusion. Think about it: calling bool() explicitly does *nothing* that Python doesn't already do, that's as silly as writing: result = int(23) + float(42.5) If they write this: if bool(x) == True: that's even more foolish. Why stop there? if bool(x) == True == True: if bool(x) == True == True == True: if bool(x) == True == True == True == True: # I never know where to stop... It may be acceptable to specifically accept *only* True and False under some (hopefully rare) circumstances: if x is True: ... elif x is False: ... else: raise TypeError but if you insist in trying to force Python to be a poor emulation of Pascal, one wonders why you don't just use Pascal. > To quote: "Let your statement be: 'Yes, yes', or "no, no': anything beyond > these is of evil." "Have you stopped abusing small children yet?" -- Steven _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor