Operator Precedence/Boolean Logic

Jon Ribbens 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 mailing list