[issue37831] bool(~True) == True

Guido van Rossum added the comment: s/book/bool/ -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37831] bool(~True) == True

Guido van Rossum added the comment: > > Because bool is embedded in int, it's okay to return a bool value *that > > compares equal to the int from the corresponding int operation*. > Agreed that it's okay, but I'd like to understand why it's considered > *desirable*. What use-cases benefit

[issue37831] bool(~True) == True

Mark Dickinson added the comment: > Because bool is embedded in int, it's okay to return a bool value *that > compares equal to the int from the corresponding int operation*. Agreed that it's okay, but I'd like to understand why it's considered *desirable*. What use-cases benefit from

[issue37831] bool(~True) == True

Guido van Rossum added the comment: It never occurred to me that making b an b|b return bool would be considered a bad thing just because ~b is not a bool. That's like complaining that 1+1 returns an int rather than a float for consistency with 1/2 returning a float. Because bool is

[issue37831] bool(~True) == True

Serhiy Storchaka added the comment: > Does anyone know what the rationale was for having & and | on bools return > bools in the first place? Besides the fact that they can be defined on bool in compatible way and these operators often are used for booleans? It was in the initial version of

[issue37831] bool(~True) == True

Mark Dickinson added the comment: [Raymond] > Given that & | and ^ are closed under bools [...] So maybe the right fix is to change that fact? I'm not sure what the value of having True & True return True rather than 1 is, beyond misleading people into thinking that bitwise operators "just

[issue37831] bool(~True) == True

Raymond Hettinger added the comment: Essentially we've got two competing desires: * Given that & | and ^ are closed under bools, it would be nice for ~ to be closed as well. NOT isn't a reasonable alternative because of its operator precedence. * Given that bool is a subclass of int,

[issue37831] bool(~True) == True

Serhiy Storchaka added the comment: :-D -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37831] bool(~True) == True

Eryk Sun added the comment: We could extend bool with shades of grey that close the 2-bit, signed set over the complement: {-2, -1, 0, 1}. For example, the bitwise complement of False could be RealNews (-1, 0x11) and the bitwise complement of True could be FakeNews (-2, 0x10). The bool()

[issue37831] bool(~True) == True

Tim Peters added the comment: BTW, I should clarify that I think the real "sin" here was making bool a subclass of int to begin with. For example, there's no sane reason at all for bools to support division, and no reason for a distinct type not to define "~" any way it feels like.

[issue37831] bool(~True) == True

Tim Peters added the comment: I don't agree that "~" doesn't "work". If people are reading it as "not", they're in error. The Python docs say ~x means the bits of x inverted and that's what it does. There's no sense it which it was _intended_ to be logical negation, no more in

[issue37831] bool(~True) == True

Raymond Hettinger added the comment: It may have been a mistake to directly support | & and ^. That implies ~ should work. The fallback is to use "not" but that looks weird and has the wrong operator precedence: (not a) ^ (not b & c) -- ___

[issue37831] bool(~True) == True

Raymond Hettinger added the comment: Okay, we'll just continue to tell users "you're holding it wrong" ;-) -- stage: -> resolved status: open -> closed ___ Python tracker

[issue37831] bool(~True) == True

Mark Dickinson added the comment: > isn't `int()` the obvious way "to convert an integer-like thing to an actual > int"? Well sorta, except that it's too lenient, letting in strings, floats, Decimal instances and the like. The strings isn't so much of an issue - it's more the silent

[issue37831] bool(~True) == True

Serhiy Storchaka added the comment: For reference, the link to the Python-Ideas discussion in Mailman 3: https://mail.python.org/archives/list/python-id...@python.org/thread/7UR3XGXNLGCM6QFR7KTIQ2QGVRS6QNZH/ -- ___ Python tracker

[issue37831] bool(~True) == True

Tim Peters added the comment: Mark, isn't `int()` the obvious way "to convert an integer-like thing to an actual int"? >>> int(True) 1 >>> int(False) 0 For the rest, I'm -True on making ~ do something magical for bools inconsistent with what it does for ints. "is-a" is a promise.

[issue37831] bool(~True) == True

Mark Dickinson added the comment: There's also the minor annoyance that there isn't currently an obvious safe way to convert an integer-like thing to an actual int, to make sure that bools do the right thing in a numeric context. operator.index *ought* to be that obvious way, but it leaves

[issue37831] bool(~True) == True

Mark Dickinson added the comment: > Making True == -1 looks interesting, but it has drawbacks. Yes, please ignore that part of my post. :-) It shouldn't be considered seriously until a time machine turns up (and probably not even then). My main worry with the proposed change is accidental

[issue37831] bool(~True) == True

Serhiy Storchaka added the comment: -1 from me too. Making True == -1 looks interesting, but it has drawbacks. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue37831] bool(~True) == True

Change by Mark Dickinson : -- stage: resolved -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37831] bool(~True) == True

Mark Dickinson added the comment: See also the discussion started by Antoine here: https://mail.python.org/pipermail//python-ideas/2016-April/039488.html -- ___ Python tracker

[issue37831] bool(~True) == True

Raymond Hettinger added the comment: +0 This proposal may be worth re-considering. I've seen the problem arise in practice on multiple occasions. I suspect that it will continue to give people trouble. Right now, a bool is-a int that 1) only has two singleton instances equal to zero and

[issue37831] bool(~True) == True

Change by Josh Rosenberg : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> ~True is not False ___ Python tracker ___

[issue37831] bool(~True) == True

Mark Dickinson added the comment: Looks like this is essentially a duplicate of #12447 -- ___ Python tracker ___ ___

[issue37831] bool(~True) == True

Mark Dickinson added the comment: For instances of `int`, `~` does bitwise negation (with the usual two's-complement with an infinite number of bits model that Python uses for all bitwise operations on arbitrary-precision integers). And rightly or wrongly, `True` and `False` are instances

[issue37831] bool(~True) == True

New submission from Tomer Vromen : Bitwise operators have inconsistent behavior when acting on bool values: (Python 3.7.4) # "&" works like "and" >>> True & True True >>> True & False False >>> False & False False # "|" works like "or" >>> True | True True >>> True | False True >>> False |