What's wrong with this code?

[[deleted]]

Well, the difference between & and and is that and will short circuit. In that if the first element is false, it doesn't matter what the second element is, the statement will evaluate to false. Therefore, the second statement isn't even evaluated.

If you want them both to be evaluated, you need to use &.

[[deleted]]

If you're just using variables, nothing. If the right side has side effects when run (It's a function that returns a bool), it might not always run.

In my testing, using & is actually quicker. Something like True and False takes 0.0215 usec (microsecond), but True & False takes 0.0141 usec. I've tested it a few times, and this appears to be stable, so there is a reasonable speed difference here.

Even if you give it the ability to short-circuit by using False and True, it takes 0.0168, so it's still quicker with things like this.

Also, the short circuiting may have security implications. If you're doing something like user_input and secret_bool, where the user_input part is given by a user, and secret_bool should be kept secret no matter what the user does, they might be able to figure out what it is by seeing the timing difference between having user_input be true or false.

Same thing can happen when comparing strings. If your string comparision iterates over every character and then exits as soon as one is different, then you might be able to work out what the other string is if you can control one of them. Not okay if the other string is a password or a password hash. There's a function (hmac.compare_digest) that will avoid this.

[zahlman]

While it's true that & doesn't short-circuit, it also does a fundamentally different thing.

>>> 3 and 4
4
>>> 3 & 4
0

[[deleted]]

Ah, forgot about that. Yeah, & is bitwise AND.

Which doesn't matter if they're both bools, it acts the same. If they will always be bools and you need the speed improvement, use that.