Isn't bool __invert__ behaviour "strange"?

[Saizan]

Why subclassing bool from int either __invert__ or __neg__ haven't been
overrided to produce a boolean negation? I suspect backwards
compatibility or something alike, but I still wonder..

And since bool can't be subclassed, to have a type like bool but with
boolean negation what do you suggest? A wrapper maybe?
(I would use it so I can evaluate user-defined boolean expression
creating istances of his/her variables in my namespace and than eval()
his/her expression)

[Bjoern Schliessmann]

Saizan wrote:

Why subclassing bool from int either __invert__ or __neg__ haven't
been overrided to produce a boolean negation?

I wonder what -True or -False should evaluate to.

Regards,
Björn

--
BOFH excuse #297:

Too many interrupts

[Saizan]

Bjoern Schliessmann wrote:

Saizan wrote:

Why subclassing bool from int either __invert__ or __neg__ haven't
been overrided to produce a boolean negation?

I wonder what -True or -False should evaluate to.

Regards,
Björn

--
BOFH excuse #297:

Too many interrupts

Well in boolean notation -True == False and -False == True, actually
you may prefer ¬ or a line over the term, but since there's no such
operator in python I think we should use "-" which is also the operator
used by Bool himself in his formulation for negation which was 1-x.
Now that I think of it 1-x should work as a negation in Python, too,
since True == 1 and False == 0, but it would be a little annoying to
write expressions in this way.

[John Roth]

Saizan wrote:

Why subclassing bool from int either __invert__ or __neg__ haven't been
overrided to produce a boolean negation? I suspect backwards
compatibility or something alike, but I still wonder..

And since bool can't be subclassed, to have a type like bool but with
boolean negation what do you suggest? A wrapper maybe?
(I would use it so I can evaluate user-defined boolean expression
creating istances of his/her variables in my namespace and than eval()
his/her expression)

The not operator and the bool() builtin produce
boolean results. Since bool is a subclass of int,
all the integer operations will remain integer
operations. This was done for backwards
compatability, and is unlikely to change in the 2.x
series.

I don't remember if this is supposed to change
in 3.0. See PEP 3100 and 3099.

John Roth

John Roth

[Carsten Haese]

On Fri, 2006-09-22 at 11:25, Saizan wrote:

Bjoern Schliessmann wrote:

Saizan wrote:

Why subclassing bool from int either __invert__ or __neg__ haven't
been overrided to produce a boolean negation?

I wonder what -True or -False should evaluate to.

Well in boolean notation -True == False and -False == True, actually
you may prefer ¬ or a line over the term, but since there's no such
operator in python [...]

It's called "not":

>>not True

False

>>not False

True

-Carsten

[Bjoern Schliessmann]

Saizan wrote:

Well in boolean notation -True == False and -False == True,
actually you may prefer ¬ or a line over the term,

(I can't remember reading "-" (minus) for a standard boolean
negation operator anywhere. Even C/C++ uses "!".)

but since there's no such operator in python I think we should
use "-"

Stop! What about the "not" operator? It's Python's operator for
negation.

which is also the operator used by Bool himself in his formulation
for negation which was 1-x.

Boole's original formulation uses some weird mathematical things to
emulate "not", "and" and "or". Focus lies on "mathematic al" here.

Now that I think of it 1-x should work as a negation in Python,
too, since True == 1 and False == 0, but it would be a little
annoying to write expressions in this way.

And "a little" unreadable ;)

Regards,
Björn

--
BOFH excuse #445:

Browser's cookie is corrupted -- someone's been nibbling on it.

[Saizan]

John Roth wrote:

The not operator and the bool() builtin produce
boolean results. Since bool is a subclass of int,
all the integer operations will remain integer
operations. This was done for backwards
compatability, and is unlikely to change in the 2.x
series.

Ok, shame on me, I completely overlooked "not" and it surprises myself
because it's not like I haven't used it, I just didn't see "not" as an
operator, maybe because i can't find a __not__ method in bool class.
(Is it hidden somewhere or is computed in some other way?)

(However (not x) whould be as annoying as 1-x even if a little more
readable (if you consider lispish parentheses readable):
Input expression: (not (not x)&(not y)!(not (z|v)))
Maybe direct eval is just the wrong way of doing this, I should look
for or make muParser bindings for Python instead..)

[Bjoern Schliessmann]

Saizan wrote:

(However (not x) whould be as annoying as 1-x even if a little
more readable (if you consider lispish parentheses readable):
Input expression: (not (not x)&(not y)!(not (z|v)))

Did you notice that you use bitwise AND and OR here? How about

not (not x) and (not y) or (not (z or v))

(or what is "!" supposed to mean?)

BTW, not's binding is stronger than and's (IIRC). So

not (not x) and (not y)

mutates to

x and (not y)

Regards,
Björn

--
BOFH excuse #392:

It's union rules. There's nothing we can do about it. Sorry.

[Paul McGuire]

"Saizan" <sa*******@gmai l.comwrote in message
news:11******** **************@ i42g2000cwa.goo glegroups.com.. .

>
John Roth wrote:

>The not operator and the bool() builtin produce
boolean results. Since bool is a subclass of int,
all the integer operations will remain integer
operations. This was done for backwards
compatabilit y, and is unlikely to change in the 2.x
series.

Ok, shame on me, I completely overlooked "not" and it surprises myself
because it's not like I haven't used it, I just didn't see "not" as an
operator, maybe because i can't find a __not__ method in bool class.
(Is it hidden somewhere or is computed in some other way?)

(However (not x) whould be as annoying as 1-x even if a little more
readable (if you consider lispish parentheses readable):
Input expression: (not (not x)&(not y)!(not (z|v)))
Maybe direct eval is just the wrong way of doing this, I should look
for or make muParser bindings for Python instead..)

What about __nonzero__?

class IsOdd(object):
def __init__(self,n ):
self.val = n

def __nonzero__(sel f):
return self.val % 2

for i in range(4):
if IsOdd(i):
print i,"is odd"
else:
print i,"is even"

Prints:
0 is even
1 is odd
2 is even
3 is odd
-- Paul

[Saizan]

Thanks for pointing that out ( the "!" is a misstyped "|"), my classes
of discrete math have warped my mind with a mix of various non-C-style
operators notation, I never use bitwise operation and this is just a
bad day for thinking about things..
However I figured out one thing, Python's logic notation is readable
and complete but not compact. (which is fine for programming, and
that's the aim, isn't it?)

Bjoern Schliessmann wrote:

Saizan wrote:

(However (not x) whould be as annoying as 1-x even if a little
more readable (if you consider lispish parentheses readable):
Input expression: (not (not x)&(not y)!(not (z|v)))

Did you notice that you use bitwise AND and OR here? How about

not (not x) and (not y) or (not (z or v))

(or what is "!" supposed to mean?)

BTW, not's binding is stronger than and's (IIRC). So

not (not x) and (not y)

mutates to

x and (not y)

Regards,
Björn

--
BOFH excuse #392:

It's union rules. There's nothing we can do about it. Sorry.