Names changed to protect the guilty

B

Ben Finney

I think I was reading the same code recently (epydoc?) and was also
momentarily horrified ;-) until I realized that it was quite
deliberately using three-valued logic (True, False, None) for some
presumably-sensible reason.

Apparently a reason unrelated to dict.has_key, which is documented as
returning only True or False, never None.
 
A

Aahz

I think I was reading the same code recently (epydoc?) and was also
momentarily horrified ;-) until I realized that it was quite
deliberately using three-valued logic (True, False, None) for some
presumably-sensible reason. Since None is false, they had to use
"is". So, given the need for three-valued logic, it's not as silly as
it looks.

My take is that even in that case, one should use "is" only with None.
There is too much ground for bugs with True/False, particularly if you
either intend to work across version *or* you might possibly accept a
user's object (because *they* might be working across versions and
therefore returning 1/0 instead of True/False). I think it's safest to
simply ban this idiom. No exceptions, never.

And, no, this wasn't epydoc.
 
L

Lawrence D'Oliveiro

Yes, but it stops after one more iteration. "What I tell you three
times is true" -- the Bellman, "The Hunting of the Snark", by Lewis
Carroll.

But that was only said once, wasn't it?
 
J

John Machin

Lawrence said:
But that was only said once, wasn't it?

And the Bellman made no statement at all about the truthfulness of
statements made any other number of times than three.
 
H

Hendrik van Rooyen

Steven D'Aprano said:
Puh-lease! Get it right!

It should be "((blah is False) is True) is True".

I once saw a baking powder tin with a picture of a baking powder tin with a
picture of a baking powder tin...

- Hendrik
 
A

Antoon Pardon

Yes, but it stops after one more iteration. "What I tell you three
times is true" -- the Bellman, "The Hunting of the Snark", by Lewis
Carroll.

Shouldn't it then be: "((blah is False) is False) is False"
 
A

Antoon Pardon

My take is that even in that case, one should use "is" only with None.
There is too much ground for bugs with True/False, particularly if you
either intend to work across version *or* you might possibly accept a
user's object (because *they* might be working across versions and
therefore returning 1/0 instead of True/False). I think it's safest to
simply ban this idiom. No exceptions, never.

The problem is there is also ground for bugs if you don't use
"blah is True". If some application naturally seems to ask
for a variable that can be valued False, True or a positive
integer then things like "if var" or "if not var" may very
well be a bug too.
 
A

Aahz

The problem is there is also ground for bugs if you don't use "blah is
True". If some application naturally seems to ask for a variable that
can be valued False, True or a positive integer then things like "if
var" or "if not var" may very well be a bug too.

Anyone designing an app like that in Python deserves to lose. It's just
another way of shooting yourself in the foot.
 
J

John J. Lee

Ben Finney said:
Apparently a reason unrelated to dict.has_key, which is documented as
returning only True or False, never None.

Yes, that's true, I didn't really take in this particular example,
just the use of "is <bool constant>". That's not the way it was used
in docutils, though (do I mean docutils?).


John
 
J

John J. Lee

My take is that even in that case, one should use "is" only with None.
There is too much ground for bugs with True/False, particularly if you
either intend to work across version *or* you might possibly accept a
user's object (because *they* might be working across versions and
therefore returning 1/0 instead of True/False). I think it's safest to
simply ban this idiom. No exceptions, never.

I tend to agree -- I think I'd define my own constants if I wanted a
three-valued logic for use with "is".


John
 
A

Andy Salnikov

Aahz said:
Anyone designing an app like that in Python deserves to lose. It's just
another way of shooting yourself in the foot.

OK, I guess nobody ever heard about three-valued logic before, right?

Of course it does not apply to the original post because has_key()
can only return True or False (I hope it will not ever return DontKnow:)
but in general if you implement something like 3-valued logic choices
like (False,True,None) are almost obvious.

Andy.
 
B

Ben Finney

Andy Salnikov said:
OK, I guess nobody ever heard about three-valued logic before,
right?

Three-valued logic is fine for some purposes. Bending boolean
two-valued constants to play the part of three-valued is confusing and
wrong.
Of course it does not apply to the original post because has_key()
can only return True or False (I hope it will not ever return
DontKnow:) but in general if you implement something like 3-valued
logic choices like (False,True,None) are almost obvious.

No. Using False and True is a strong signal to the reader that you're
using *two* value logic. If you break that expectation, the reader
should not be expected to sympathise.

As another poster suggested, if you want to implement three-valued
logic, use three new objects to represent the states, so the reader
*knows* there's something going on other than two-value logic. Don't
re-use False and True in three-valued logic and expect anyone to
understand your code.
 
A

Antoon Pardon

Anyone designing an app like that in Python deserves to lose. It's just
another way of shooting yourself in the foot.

Why? Just because you don't like it? The last time I mentioned this,
all those who propsed an alternative implemenation came with proposals
that couldn't work, while I never had problems with my code.
 
A

Antoon Pardon

Three-valued logic is fine for some purposes. Bending boolean
two-valued constants to play the part of three-valued is confusing and
wrong.

Why? The variable in question gives an answer to the question:

Has the user requested a connection.

To which the answer can be:

1: No
2: Yes
3: Yes and the connection ID is ...

So tell me what is wrong with using False and True for the simple
No and Yes answer in this case?
No. Using False and True is a strong signal to the reader that you're
using *two* value logic. If you break that expectation, the reader
should not be expected to sympathise.

IMO that expectation is unpythonic. Python allows that a variable
can be of different types during its lifetime. There is even no
mechanism to limit a variable to a specific type. So there is no
reason to expect a variable is limited to False and True just
because one of those was used. Just as there is no reason to
expect a variable will always be an integer just because it
was assigned an integer constant at some point.
As another poster suggested, if you want to implement three-valued
logic, use three new objects to represent the states, so the reader
*knows* there's something going on other than two-value logic. Don't
re-use False and True in three-valued logic and expect anyone to
understand your code.

I thought that was the purpose of documentation.
 
J

John J. Lee

Yes, that's true, I didn't really take in this particular example,
just the use of "is <bool constant>". That's not the way it was used
in docutils, though (do I mean docutils?).

No, I meant epydoc (I think...)


John
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,434
Messages
2,571,689
Members
48,796
Latest member
Greg L.

Latest Threads

Top