By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,768 Members | 2,054 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,768 IT Pros & Developers. It's quick & easy.

Names changed to protect the guilty

P: n/a
The following line of lightly munged code was found in a publicly
available Python library...

if schema.elements.has_key(key) is False:

Sorry, just had to vent.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
Oct 6 '06 #1
Share this Question
Share on Google+
37 Replies


P: n/a


On Oct 6, 6:27 pm, a...@pythoncraft.com (Aahz) wrote:
The following line of lightly munged code was found in a publicly
available Python library...
Yes, this violates the Holy, Inspired, Infallible Style Guide (pbuh),
which was written by the very finger of God when the world was still in
chaotic darkness. But I guess I'm an atheist when it comes to PEP 8. If
it is clearer to you to make the condition explicit ("blah not False"),
rather than implicit ("not blah"), then use the former. I say write the
code the way *you* (and your team if applicable) are best able to read,
write and maintain it. Then when other people tell you that it isn't
good style, or isn't "pythonic," just stab them in the face with
soldering iron ala Chris Walken. :)

Regards,
Jordan

Oct 7 '06 #2

P: n/a


On Oct 6, 8:02 pm, "MonkeeSage" <MonkeeS...@gmail.comwrote:
it is clearer to you to make the condition explicit ("blah not False"),
"blah not False" -"blah is False"

Oct 7 '06 #3

P: n/a
On 2006-10-07, MonkeeSage <Mo********@gmail.comwrote:
>

On Oct 6, 6:27 pm, a...@pythoncraft.com (Aahz) wrote:
>The following line of lightly munged code was found in a
publicly available Python library...

Yes, this violates the Holy, Inspired, Infallible Style Guide
(pbuh), which was written by the very finger of God when the
world was still in chaotic darkness. But I guess I'm an atheist
when it comes to PEP 8. If it is clearer to you to make the
condition explicit ("blah not False"), rather than implicit
("not blah"), then use the former. I say write the code the way
*you* (and your team if applicable) are best able to read,
write and maintain it. Then when other people tell you that it
isn't good style, or isn't "pythonic," just stab them in the
face with soldering iron ala Chris Walken. :)
I agree on both points. It's a style issue, and that hidden tests
(taking advantage of how certain objects convert to boolian
values) is harder to read.

--
Neil Cerutti
Oct 7 '06 #4

P: n/a

MonkeeSage wrote:
On Oct 6, 8:02 pm, "MonkeeSage" <MonkeeS...@gmail.comwrote:
it is clearer to you to make the condition explicit ("blah not False"),

"blah not False" -"blah is False"
Whichever way your team wants to interpret it, d00d.

Please consider whether you should be writing "(blah is False) is
True", that would be more explicit.

Oct 7 '06 #5

P: n/a
On 2006-10-07, John Machin <sj******@lexicon.netwrote:
>
MonkeeSage wrote:
>On Oct 6, 8:02 pm, "MonkeeSage" <MonkeeS...@gmail.comwrote:
it is clearer to you to make the condition explicit ("blah not False"),

"blah not False" -"blah is False"

Whichever way your team wants to interpret it, d00d.

Please consider whether you should be writing "(blah is False)
is True", that would be more explicit.
OK, now we're entering Daily WTF territory. ;)

And in the original case, I'd agree that "if X.has_key():" is
quite clear, already yielding a boolian value, and so doesn't
need to be tested for if it's False. But I wouldn't like to test
for an empty list or for None implicitly.

--
Neil Cerutti
Oct 7 '06 #6

P: n/a
At Friday 6/10/2006 22:02, MonkeeSage wrote:
The following line of lightly munged code was found in a publicly
available Python library...

Yes, this violates the Holy, Inspired, Infallible Style Guide (pbuh),
which was written by the very finger of God when the world was still in
It's not about style or being pythonic: a condition may be false, but
not the False object itself, so writing
if something is False:
is the wrong way to test if something is false (isn't clear? :) )
>>def is_odd_number(n): return n & 1
....
>>if is_odd_number(3) is False: print "3 is odd"
.... else: print "3 is even"
....
3 is even
Gabriel Genellina
Softlab SRL

__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

Oct 7 '06 #7

P: n/a
On 6 Oct 2006 16:27:51 -0700, Aahz <aa**@pythoncraft.comwrote:
The following line of lightly munged code was found in a publicly
available Python library...

if schema.elements.has_key(key) is False:
if not schema.elements.has_key(key): or, actually, if not key in
schema.elements: is how I would write it, but this reads more like
English.

-- Theerasak
Oct 7 '06 #8

P: n/a

On Oct 6, 8:34 pm, Neil Cerutti <horp...@yahoo.comwrote:
And in the original case, I'd agree that "if X.has_key():" is
quite clear, already yielding a boolian value, and so doesn't
need to be tested for if it's False. But I wouldn't like to test
for an empty list or for None implicitly.
I agree that predicates are explicit in themselves, if they are named
intuitively like "has_key". I assumed that the OP was upset about "is
False" not that an explicit check was done on a predicate method.

On Oct 6, 8:38 pm, Gabriel Genellina <gagsl...@yahoo.com.arwrote:
It's not about style or being pythonic: a condition may be false, but
not the False object itself, so writing
if something is False:
is the wrong way to test if something is false (isn't clear? :) )
Yes, I understand, and it's true that in a mixed context it could bite
you (or you could check equality rather than identity), but assuming a
strictly boolean context you don't have that problem (or perhaps you
even *want* to differentiate between False, None and 0 in a mixed
context).

Ps. I mostly use the "if (not) cond" form. But I take the style guide
as a, well, *guide*, rather than a style *law* and I tend to get
annoyed when people get religious about things like that. Subjective
taste, be it GvR's or the Pope's, is -- subjective. On the other hand,
if lightening is flashing and seas are parting and stuff, I don;t tend
to argue too much in that case. ;)

Regards,
Jordan

Oct 7 '06 #9

P: n/a

MonkeeSage wrote:
On Oct 6, 6:27 pm, a...@pythoncraft.com (Aahz) wrote:
The following line of lightly munged code was found in a publicly
available Python library...

Yes, this violates the Holy, Inspired, Infallible Style Guide (pbuh),
which was written by the very finger of God when the world was still in
chaotic darkness. But I guess I'm an atheist when it comes to PEP 8. If
it is clearer to you to make the condition explicit ("blah not False"),
rather than implicit ("not blah"), then use the former. I say write the
code the way *you* (and your team if applicable) are best able to read,
write and maintain it. Then when other people tell you that it isn't
good style, or isn't "pythonic," just stab them in the face with
soldering iron ala Chris Walken. :)

Regards,
Jordan
I don't think it's even a matter of "If it's clearer to *you*", it's a
matter of not writing code while drunk. Isn't something like "key not
in schema.elements" universally clearer than the above mess? (If
elements has a "has_key()" method, it probably is or acts like a dict)

But I don't blame the autor of this line (The drunk thing was a joke),
I can see how it can happen: editing. You write something, and the
oops, it doesn't quite work, make a quick fix, then another, then
another. You end up with something that works, but don't notice the
ugly line you left. It happens.

However, it can *also* happen when you write code while drunk...

Oct 7 '06 #10

P: n/a
In article <11**********************@i42g2000cwa.googlegroups .com>,
MonkeeSage <Mo********@gmail.comwrote:
>On Oct 6, 6:27 pm, a...@pythoncraft.com (Aahz) wrote:
>>
The following line of lightly munged code was found in a publicly
available Python library...

Yes, this violates the Holy, Inspired, Infallible Style Guide (pbuh),
which was written by the very finger of God when the world was still in
chaotic darkness.
Did you actually analyze the line of code? Particularly WRT the way it
operates in different versions of Python?
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
Oct 7 '06 #11

P: n/a

Aahz wrote:
In article <11**********************@i42g2000cwa.googlegroups .com>,
MonkeeSage <Mo********@gmail.comwrote:
On Oct 6, 6:27 pm, a...@pythoncraft.com (Aahz) wrote:
>
The following line of lightly munged code was found in a publicly
available Python library...
Yes, this violates the Holy, Inspired, Infallible Style Guide (pbuh),
which was written by the very finger of God when the world was still in
chaotic darkness.

Did you actually analyze the line of code? Particularly WRT the way it
operates in different versions of Python?
A comment on the "style" issue, before we get into the real WTF
analysis: any function/method whose name begins with "has" or "is"
returns an honest-to-goodness actual bool (or what passed for one in
former times). IMHO, any comparison with [] being regarded as false and
[0] being regarded as true is irrelevant, and writing "has_something()
== False" or "has_something() is False" is utterly ludicrous.

Now back to the analysis. Empirical evidence, back as far as 2.1:

C:\junk>type isfalse.py
import sys
print sys.version
try:
False
print "False is defined; type: %r; value: %r" \
% (type(False), False)
except NameError:
print "defining: False = 0; True = 1"
False = 0
True = 1
adict = {1: 42}
v = adict.has_key(2)
print "'adict.has_key(2)' ->", v
print "'adict.has_key(2) == False' ->", v == False
print "'adict.has_key(2) is False' ->", v is False
try:
1 in adict
print "'key in adict' is available"
except TypeError, e:
print "Need to use 'adict.has_key(key)'"
print "'key in adict' -%s" % e
C:\junk>for %1 in (5 4 3 2 1) do \python2%1\python isfalse.py

C:\junk>\python25\python isfalse.py
2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
False is defined; type: <type 'bool'>; value: False
'adict.has_key(2)' -False
'adict.has_key(2) == False' -True
'adict.has_key(2) is False' -True
'key in adict' is available

C:\junk>\python24\python isfalse.py
2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)]
False is defined; type: <type 'bool'>; value: False
'adict.has_key(2)' -False
'adict.has_key(2) == False' -True
'adict.has_key(2) is False' -True
'key in adict' is available

C:\junk>\python23\python isfalse.py
2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)]
False is defined; type: <type 'bool'>; value: False
'adict.has_key(2)' -False
'adict.has_key(2) == False' -True
'adict.has_key(2) is False' -True
'key in adict' is available

C:\junk>\python22\python isfalse.py
2.2.3 (#42, May 30 2003, 18:12:08) [MSC 32 bit (Intel)]
False is defined; type: <type 'int'>; value: 0
'adict.has_key(2)' -0
'adict.has_key(2) == False' -1
'adict.has_key(2) is False' -0
'key in adict' is available

C:\junk>\python21\python isfalse.py
2.1.3 (#35, Apr 8 2002, 17:47:50) [MSC 32 bit (Intel)]
defining: False = 0; True = 1
'adict.has_key(2)' -0
'adict.has_key(2) == False' -1
'adict.has_key(2) is False' -1
Need to use 'adict.has_key(key)'
'key in adict' -'in' or 'not in' needs sequence right argument

Analysis depends on what range of Python versions the author purported
to be supporting:
(1) back to 2.3: bad style, no damage, but why not use "key in dict"?
(2) back to 2.2: bad style, *WRONG ANSWER*; why not use "key in dict"?
(3) back to 2.1: as above for 2.2; would not work in 2.1 without the
demonstrated band-aid. Note that the simple "if not
adict.has_key(key):" construct works happily (if a trifle slowly) in
all 5 versions.

HTH,
John

Oct 7 '06 #12

P: n/a
On 2006-10-07, MonkeeSage <Mo********@gmail.comwrote:
>
On Oct 6, 8:34 pm, Neil Cerutti <horp...@yahoo.comwrote:
>And in the original case, I'd agree that "if X.has_key():" is
quite clear, already yielding a boolian value, and so doesn't
need to be tested for if it's False. But I wouldn't like to
test for an empty list or for None implicitly.

I agree that predicates are explicit in themselves, if they are
named intuitively like "has_key". I assumed that the OP was
upset about "is False" not that an explicit check was done on a
predicate method.
And that's something that I'd never have written, and wouldn't
have recognized as a bug until this thread. I can hear the gears
clicking in there now. Thanks to you and other that explained
this bug properly.

--
Neil Cerutti
Oct 7 '06 #13

P: n/a
On Fri, 06 Oct 2006 18:29:34 -0700, John Machin wrote:
>
MonkeeSage wrote:
>On Oct 6, 8:02 pm, "MonkeeSage" <MonkeeS...@gmail.comwrote:
it is clearer to you to make the condition explicit ("blah not False"),

"blah not False" -"blah is False"

Whichever way your team wants to interpret it, d00d.

Please consider whether you should be writing "(blah is False) is
True", that would be more explicit.
Puh-lease! Get it right!

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

--
Steve.

Oct 7 '06 #14

P: n/a

Steven D'Aprano wrote:
On Fri, 06 Oct 2006 18:29:34 -0700, John Machin wrote:

MonkeeSage wrote:
On Oct 6, 8:02 pm, "MonkeeSage" <MonkeeS...@gmail.comwrote:
it is clearer to you to make the condition explicit ("blah not False"),

"blah not False" -"blah is False"
Whichever way your team wants to interpret it, d00d.

Please consider whether you should be writing "(blah is False) is
True", that would be more explicit.

Puh-lease! Get it right!

It should be "((blah is False) is True) is True".
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.

Oct 7 '06 #15

P: n/a

Aahz wrote:
The following line of lightly munged code was found in a publicly
available Python library...

if schema.elements.has_key(key) is False:

Sorry, just had to vent.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/
Uh, guys. IMO, the clearest way of writing this is:

if key not in schema.elements:
whatever...

Unless, of course, your code has to run in a
Python release earlier than 2.2. But then you
wouldn't be testing for the False object anyway.

John Roth

Oct 7 '06 #16

P: n/a

John Roth wrote:
Aahz wrote:
The following line of lightly munged code was found in a publicly
available Python library...

if schema.elements.has_key(key) is False:

Sorry, just had to vent.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

Uh, guys. IMO, the clearest way of writing this is:

if key not in schema.elements:
whatever...
Uh, guys, what? You are the 3rd to make that point. Therefore it must
be true.
Unless, of course, your code has to run in a
Python release earlier than 2.2. But then you
wouldn't be testing for the False object anyway.

John Roth
Oct 7 '06 #17

P: n/a
In article <11**********************@i42g2000cwa.googlegroups .com>,
John Machin <sj******@lexicon.netwrote:
>Aahz wrote:
>In article <11**********************@i42g2000cwa.googlegroups .com>,
MonkeeSage <Mo********@gmail.comwrote:
>>>On Oct 6, 6:27 pm, a...@pythoncraft.com (Aahz) wrote:

The following line of lightly munged code was found in a publicly
available Python library...

Yes, this violates the Holy, Inspired, Infallible Style Guide (pbuh),
which was written by the very finger of God when the world was still in
chaotic darkness.

Did you actually analyze the line of code? Particularly WRT the way it
operates in different versions of Python?

A comment on the "style" issue, before we get into the real WTF
analysis: any function/method whose name begins with "has" or "is"
returns an honest-to-goodness actual bool (or what passed for one in
former times). IMHO, any comparison with [] being regarded as false and
[0] being regarded as true is irrelevant, and writing "has_something()
== False" or "has_something() is False" is utterly ludicrous.
Exactly. Another way of putting this: it's so wrong, it isn't even
wrong.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
Oct 7 '06 #18

P: n/a
John Machin wrote:
... any function/method whose name begins with "has" or "is"
returns an honest-to-goodness actual bool (or what passed for
one in former times).
True for 75% of the builtins:
>>import __builtin__
sorted(nm for nm in dir(__builtin__)
if nm.startswith('is') or nm.startswith('has'))
['hasattr', 'hash', 'isinstance', 'issubclass']
>>[hasattr(type,'mro'), hash(123), isinstance(type, type),
issubclass(type, type)]
[True, 123, True, True]

:-)

--Scott David Daniels
sc***********@acm.org
Oct 7 '06 #19

P: n/a
aa**@pythoncraft.com (Aahz) writes:
The following line of lightly munged code was found in a publicly
available Python library...

if schema.elements.has_key(key) is False:

Sorry, just had to vent.
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.
John
Oct 8 '06 #20

P: n/a
jj*@pobox.com (John J. Lee) writes:
aa**@pythoncraft.com (Aahz) writes:
if schema.elements.has_key(key) is False:

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.

--
\ "Welchen Teil von 'Gestalt' verstehen Sie nicht? [What part of |
`\ 'gestalt' don't you understand?]" -- Karsten M. Self |
_o__) |
Ben Finney

Oct 8 '06 #21

P: n/a
In article <87************@pobox.com>, John J. Lee <jj*@pobox.comwrote:
>aa**@pythoncraft.com (Aahz) writes:
>>
The following line of lightly munged code was found in a publicly
available Python library...

if schema.elements.has_key(key) is False:

Sorry, just had to vent.

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.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
Oct 8 '06 #22

P: n/a
In message <11**********************@b28g2000cwb.googlegroups .com>, John
Machin wrote:
>
Steven D'Aprano wrote:
>On Fri, 06 Oct 2006 18:29:34 -0700, John Machin wrote:
>
MonkeeSage wrote:
On Oct 6, 8:02 pm, "MonkeeSage" <MonkeeS...@gmail.comwrote:
it is clearer to you to make the condition explicit ("blah not
False"),

"blah not False" -"blah is False"

Whichever way your team wants to interpret it, d00d.

Please consider whether you should be writing "(blah is False) is
True", that would be more explicit.

Puh-lease! Get it right!

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

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?
Oct 8 '06 #23

P: n/a

Lawrence D'Oliveiro wrote:
In message <11**********************@b28g2000cwb.googlegroups .com>, John
Machin wrote:

Steven D'Aprano wrote:
On Fri, 06 Oct 2006 18:29:34 -0700, John Machin wrote:


MonkeeSage wrote:
On Oct 6, 8:02 pm, "MonkeeSage" <MonkeeS...@gmail.comwrote:
it is clearer to you to make the condition explicit ("blah not
False"),

"blah not False" -"blah is False"

Whichever way your team wants to interpret it, d00d.

Please consider whether you should be writing "(blah is False) is
True", that would be more explicit.

Puh-lease! Get it right!

It should be "((blah is False) is True) is True".
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?
Oct 8 '06 #24

P: n/a

Lawrence D'Oliveiro wrote:
In message <11**********************@b28g2000cwb.googlegroups .com>, John
Machin wrote:

Steven D'Aprano wrote:
On Fri, 06 Oct 2006 18:29:34 -0700, John Machin wrote:


MonkeeSage wrote:
On Oct 6, 8:02 pm, "MonkeeSage" <MonkeeS...@gmail.comwrote:
it is clearer to you to make the condition explicit ("blah not
False"),

"blah not False" -"blah is False"

Whichever way your team wants to interpret it, d00d.

Please consider whether you should be writing "(blah is False) is
True", that would be more explicit.

Puh-lease! Get it right!

It should be "((blah is False) is True) is True".
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?
And the Bellman made no statement at all about the truthfulness of
statements made any other number of times than three.

Oct 8 '06 #25

P: n/a
Google has a cool new service.

http://www.google.com/codesearch

You can use regular expressions!

(I found at least 13 distinct utilities that used the idiom.)

Nils
Oct 8 '06 #26

P: n/a
"Steven D'Aprano" <st***@REMOVE.THIS.cybersource.com.auwrote:
On Fri, 06 Oct 2006 18:29:34 -0700, John Machin wrote:
MonkeeSage wrote:
On Oct 6, 8:02 pm, "MonkeeSage" <MonkeeS...@gmail.comwrote:
it is clearer to you to make the condition explicit ("blah not False"),

"blah not False" -"blah is False"
Whichever way your team wants to interpret it, d00d.

Please consider whether you should be writing "(blah is False) is
True", that would be more explicit.

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
Oct 9 '06 #27

P: n/a
On 2006-10-07, John Machin <sj******@lexicon.netwrote:
>
Steven D'Aprano wrote:
>On Fri, 06 Oct 2006 18:29:34 -0700, John Machin wrote:
>
MonkeeSage wrote:
On Oct 6, 8:02 pm, "MonkeeSage" <MonkeeS...@gmail.comwrote:
it is clearer to you to make the condition explicit ("blah not False"),

"blah not False" -"blah is False"

Whichever way your team wants to interpret it, d00d.

Please consider whether you should be writing "(blah is False) is
True", that would be more explicit.

Puh-lease! Get it right!

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

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"

--
Antoon Pardon
Oct 9 '06 #28

P: n/a
On 2006-10-08, Aahz <aa**@pythoncraft.comwrote:
In article <87************@pobox.com>, John J. Lee <jj*@pobox.comwrote:
>>aa**@pythoncraft.com (Aahz) writes:
>>>
The following line of lightly munged code was found in a publicly
available Python library...

if schema.elements.has_key(key) is False:

Sorry, just had to vent.

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.
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.

--
Antoon Pardon
Oct 9 '06 #29

P: n/a
Antoon Pardon wrote:
On 2006-10-07, John Machin <sj******@lexicon.netwrote:
>>Steven D'Aprano wrote:
>>>On Fri, 06 Oct 2006 18:29:34 -0700, John Machin wrote:
MonkeeSage wrote:

>On Oct 6, 8:02 pm, "MonkeeSage" <MonkeeS...@gmail.comwrote:
>
>>it is clearer to you to make the condition explicit ("blah not False"),
>
>"blah not False" -"blah is False"

Whichever way your team wants to interpret it, d00d.

Please consider whether you should be writing "(blah is False) is
True", that would be more explicit.

Puh-lease! Get it right!

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

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"
No, that would be

"((blah is True) is False) is True"

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

Oct 9 '06 #30

P: n/a
In article <sl********************@rcpc42.vub.ac.be>,
Antoon Pardon <ap*****@forel.vub.ac.bewrote:
>On 2006-10-08, Aahz <aa**@pythoncraft.comwrote:
>In article <87************@pobox.com>, John J. Lee <jj*@pobox.comwrote:
>>>aa**@pythoncraft.com (Aahz) writes:

The following line of lightly munged code was found in a publicly
available Python library...

if schema.elements.has_key(key) is False:

Sorry, just had to vent.

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.

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.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
Oct 9 '06 #31

P: n/a
Ben Finney <bi****************@benfinney.id.auwrites:
jj*@pobox.com (John J. Lee) writes:
aa**@pythoncraft.com (Aahz) writes:
if schema.elements.has_key(key) is False:
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.
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
Oct 9 '06 #32

P: n/a
aa**@pythoncraft.com (Aahz) writes:
[...]
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.
I tend to agree -- I think I'd define my own constants if I wanted a
three-valued logic for use with "is".
John
Oct 9 '06 #33

P: n/a

"Aahz" <aa**@pythoncraft.comwrote in message
news:eg**********@panix3.panix.com...
In article <sl********************@rcpc42.vub.ac.be>, Antoon Pardon
<ap*****@forel.vub.ac.bewrote:
>>
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.
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.
Oct 10 '06 #34

P: n/a
"Andy Salnikov" <a_********@yahoo.comwrites:
"Aahz" <aa**@pythoncraft.comwrote:
Antoon Pardon <ap*****@forel.vub.ac.bewrote:
>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.

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.

--
\ "It is seldom that liberty of any kind is lost all at once." |
`\ -- David Hume |
_o__) |
Ben Finney

Oct 10 '06 #35

P: n/a
On 2006-10-09, Aahz <aa**@pythoncraft.comwrote:
In article <sl********************@rcpc42.vub.ac.be>,
Antoon Pardon <ap*****@forel.vub.ac.bewrote:
>>On 2006-10-08, Aahz <aa**@pythoncraft.comwrote:
>>In article <87************@pobox.com>, John J. Lee <jj*@pobox.comwrote:
aa**@pythoncraft.com (Aahz) writes:
>
The following line of lightly munged code was found in a publicly
available Python library...
>
if schema.elements.has_key(key) is False:
>
Sorry, just had to vent.

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.

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.
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.

--
Antoon Pardon
Oct 10 '06 #36

P: n/a
On 2006-10-10, Ben Finney <bi****************@benfinney.id.auwrote:
"Andy Salnikov" <a_********@yahoo.comwrites:
>"Aahz" <aa**@pythoncraft.comwrote:
Antoon Pardon <ap*****@forel.vub.ac.bewrote:
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.

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.
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?
>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.
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.

--
Antoon Pardon
Oct 10 '06 #37

P: n/a
jj*@pobox.com (John J. Lee) writes:
[...]
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

Oct 10 '06 #38

This discussion thread is closed

Replies have been disabled for this discussion.