Re: Names changed to protect the guilty
On 2006-10-09, Aahz [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Antoon Pardon [EMAIL PROTECTED] wrote: On 2006-10-08, Aahz [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], John J. Lee [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
On 2006-10-10, Ben Finney [EMAIL PROTECTED] wrote: Andy Salnikov [EMAIL PROTECTED] writes: Aahz [EMAIL PROTECTED] wrote: Antoon Pardon [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
[EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
Steven D'Aprano [EMAIL PROTECTED] wrote: On Fri, 06 Oct 2006 18:29:34 -0700, John Machin wrote: MonkeeSage wrote: On Oct 6, 8:02 pm, MonkeeSage [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
On 2006-10-07, John Machin [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
Antoon Pardon wrote: On 2006-10-07, John Machin [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
On 2006-10-08, Aahz [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], John J. Lee [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
In article [EMAIL PROTECTED], Antoon Pardon [EMAIL PROTECTED] wrote: On 2006-10-08, Aahz [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], John J. Lee [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (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 ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you don't know what your program is supposed to do, you'd better not start writing it. --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
Ben Finney [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (John J. Lee) writes: [EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
[EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
Aahz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] In article [EMAIL PROTECTED], Antoon Pardon [EMAIL PROTECTED] wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
Andy Salnikov [EMAIL PROTECTED] writes: Aahz [EMAIL PROTECTED] wrote: Antoon Pardon [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
In message [EMAIL PROTECTED], 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 [EMAIL PROTECTED] wrote: 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
Lawrence D'Oliveiro wrote: In message [EMAIL PROTECTED], 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 [EMAIL PROTECTED] wrote: 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
Lawrence D'Oliveiro wrote: In message [EMAIL PROTECTED], 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 [EMAIL PROTECTED] wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Google code search (Was: Names changed to protect the guilty)
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
Aahz wrote:
In article [EMAIL PROTECTED],
MonkeeSage [EMAIL PROTECTED] wrote:
On Oct 6, 6:27 pm, [EMAIL PROTECTED] (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:\junktype 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:\junkfor %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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
On 2006-10-07, MonkeeSage [EMAIL PROTECTED] wrote: On Oct 6, 8:34 pm, Neil Cerutti [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
On Fri, 06 Oct 2006 18:29:34 -0700, John Machin wrote: MonkeeSage wrote: On Oct 6, 8:02 pm, MonkeeSage [EMAIL PROTECTED] wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
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 [EMAIL PROTECTED] wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
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 ([EMAIL PROTECTED]) * 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
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 ([EMAIL PROTECTED]) * 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
In article [EMAIL PROTECTED], John Machin [EMAIL PROTECTED] wrote: Aahz wrote: In article [EMAIL PROTECTED], MonkeeSage [EMAIL PROTECTED] wrote: On Oct 6, 6:27 pm, [EMAIL PROTECTED] (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 ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you don't know what your program is supposed to do, you'd better not start writing it. --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
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
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
[EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
[EMAIL PROTECTED] (John J. Lee) writes: [EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
In article [EMAIL PROTECTED], John J. Lee [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (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 ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you don't know what your program is supposed to do, you'd better not start writing it. --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
Names changed to protect the guilty
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 ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you don't know what your program is supposed to do, you'd better not start writing it. --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
On Oct 6, 6:27 pm, [EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
On Oct 6, 8:02 pm, MonkeeSage [EMAIL PROTECTED] wrote: it is clearer to you to make the condition explicit (blah not False), blah not False - blah is False -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
On 2006-10-07, MonkeeSage [EMAIL PROTECTED] wrote: On Oct 6, 6:27 pm, [EMAIL PROTECTED] (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
MonkeeSage wrote: On Oct 6, 8:02 pm, MonkeeSage [EMAIL PROTECTED] wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
On 2006-10-07, John Machin [EMAIL PROTECTED] wrote: MonkeeSage wrote: On Oct 6, 8:02 pm, MonkeeSage [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
On 6 Oct 2006 16:27:51 -0700, Aahz [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
On Oct 6, 8:34 pm, Neil Cerutti [EMAIL PROTECTED] wrote: 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 [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
MonkeeSage wrote: On Oct 6, 6:27 pm, [EMAIL PROTECTED] (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... -- http://mail.python.org/mailman/listinfo/python-list
Re: Names changed to protect the guilty
In article [EMAIL PROTECTED], MonkeeSage [EMAIL PROTECTED] wrote: On Oct 6, 6:27 pm, [EMAIL PROTECTED] (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 ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ If you don't know what your program is supposed to do, you'd better not start writing it. --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
