Hacker News Reader

Comment by cma | Hacker News Reader

Eww.. This isn't new in 3.9, but is mentioned in the dict section as an existing quirk of sets I didn't realize this:

    >>> {0} | {False}
    {0}
    >>> {False} | {0}
    {False}

View on HN

0 == False, right? So any set-like container that uses == and not `is` for equality checks would have to only ever include one of 0 and False. This seems fine to me.

This should stop in a type error just like `0 + False` or `1 + "1"`. This code is almost always a programmer error.

Yeah I wish they didn't let you do arithmetic on Boolean with int without explicit conversion. It can be useful, but the explicit conversion isn't a large burden and prevents many errors.

It's for backwards compatibility. Which everyone who complains about 2 vs 3 should understand.

Before bool existed, some folks had a habit of writing `False = 0` and `True = 1` for readability.

that's amusing, because that's the kind of thing that people love to dunk on javascript about

Never seen that before. Neat how the bool being a subclass of int pokes out in various ways.

A nice side effect is that bools can used with sum:

    sum(x % 10 for x in range(1000))

It's not really a bool/int subclass issue but one of hash() and equality.

    >>> {1} | {1.0}
    {1}
    >>> {1.0} | {1}
    {1.0}
    >>> import fractions
    >>> x = fractions.Fraction(1)
    >>> {x} | {1}
    {Fraction(1, 1)}
    >>> {1} | {x}
    {1}

Bad example? x % 10 does not return a bool.

Whoops!

For future internet historians, it should have been:

    sum(x % 10 == 0 for x in range(1000))

Reply on news.ycombinator.com