R. David Murray added the comment: I mistyped 'josh' as 'joel', sorry.
Ethan covers it pretty well, but I'll add a few things. Boolean operators are indeed not always used in a boolean context. There is a long tradition in Python of using them to return values via the short-circuit mechanism. Python is not the only language that does this. That said, there are disadvantages to that use of boolean operators, and eventually the trinary expression 'x if y else z' was introduced, and is now the preferred way to compute such values. The tutorial has not been updated to reflect that, and that is something that could be done, but probably requires a significant rewrite...someone on irc pointed out that the passage we are discussing is the first introduction of 'or' in the tutorial). However, the short-circuit-and-value-returning behavior of the boolean operators will not change, since it is a long standing part of the language. Your suggestion that this whole thing be discussed more is a valid point, but the question is, is this point in the tutorial the place to do it? Again, a more extensive rewrite is probably needed in order to make a real improvement (a project that is being discussed, whose status I don't know). Finally, the 4.1 text you quote is noting and/or as an exception is talking about the built-in functions and operators. and and or are important exceptions both because their default is different from other logical operations and because, unlike the other python operators, a type cannot override them. Thus they always return a value, whereas other *logical* operations will return a boolean *unless otherwise documented* in the documentation for the type. (I'm not sure there are any exceptions to that in the sdtlib, but there are, for example, in numpy.) Now, that all said, the tutorial section explicitly mentions the behavior of and and or, so I don't see how their being exceptional in this regard is an issue with the tutorial text. If you assigned another logical expression to a variable, you'd get True or False, but in Python's philosophy that's just a special case of the fact that all values in python have a truth value, as discussed by Ethan. So, in summary, I hear you that as an experienced programmer this tutorial section did not give you all the information you wanted. However, it is a *tutorial*, and so it *can't* (and be a readable *tutorial*) cover all the issues. Perhaps it could cover more if it were rewritten, but I don't think changing this section in any of the ways suggested so far would, as it is currently organized, be an improvement. If anyone wants to take another stab at it, though, we'll definitely evaluate it. willingc on IRC suggested adding links to other parts of the docs, for further reading, and that might be worthwhile if someone wants to take a look at making a suggestion in that regard. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23153> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
