Operator Precedence/Boolean Logic
jon+usenet at unequivocal.eu
Wed Jun 29 11:05:25 EDT 2016
On 2016-06-29, Grant Edwards <grant.b.edwards at gmail.com> wrote:
> On 2016-06-29, Steven D'Aprano <steve at pearwood.info> wrote:
>> To Nick, having 1+True return 2 is an accident of implementation,
> My recollection is that it was not an accident of impliementation. It
> was an intentional descision to provide compatibility with many years
> worth of programs that were written before there was either a boolean
> type or built-in True/False integer values.
> Those programs often did this at the top:
> True = 1
> False = 0
> Having True and False evaluate as 1 and 0 in an integer expression
> context guaranteed that those programs would to continue to work with
> minimal changes.
I thought it was more for things like this:
"%d widget%s" % (widgets, (widgets != 1) * "s")
i.e. using boolean expressions as numeric expressions, rather than
explicitly setting the identifiers True and False to be numbers.
More information about the Python-list