On 12/2/10 2:02 AM, Harishankar wrote: > On Thu, 02 Dec 2010 00:15:42 -0800, Alice Bevan–McGregor wrote: >> The bool type is a subclass of int! (Run those lines in a Python >> interpreter to see. ;) >> >>> if var == False: >> >> if var is False: … > > So "var is False" is safer to use when I want to specifically check > whether var is set to False and not 0 or None?
Equality is a somewhat fuzzy concept. By convention and habit, its usually fine and clear: but its still fuzzy and up to each individual object involved to answer the question of equality. Now, its generally suggested in Python to do fairly vague truth testing: "if x" and "if not x" as opposed to concepts like "if x == True" and "if x == False" because the former is broad but usually more correct, and the latter can lead to some unexpected semantics. But that doesn't mean you must never check if something is False or True: there are times when you really do want or need to see if _False_ is what's being returned, or _True_, or _None_. In this case, use "is", yes, indeed. The "is" operator checks absolute object identity, and so is how you should do that check in cases where you want to test the distinction between "Is it /False/, or just something false-ish or not-true or nothing-ish?" Generally speaking in Python, you usually want to do tests as "if x" or "if not x". But sometimes you need to know if "x" is a specific singleton value: True, False or None. In that case, its okay to do "if x is True", "if x is False" or "if x is None". But you should only do that after the simple test is deemed inappropriate in your API or situation. And-- here's the rub-- while "is" is absolutely OK and right for you to use to test if an object is one of those singletons, its *probably* NOT what you want to do in any other situation*. Outside of the True/False/None singletons, and places where you're doing some special OOP-stuff, you almost certainly don't want to use 'is', but use equality checking (even if its fuzzy, because its fuzzy) instead. This demonstrates why "is" should be avoided except when in those singleton situations (except when you need to, of course): >>> a = 2 >>> b = 2 >>> a is b True >>> a == b True >>> a = 20000 >>> b = 20000 >>> a is b False >>> a == b True (If you're wondering why that's happening: Python makes very little in the way of promises with regard to object identity. It may choose to make a whole new int object of value 2 every time you type 2, or use the same old int object each time: sure, presently it tends to only share "small" integers for re-use, but that's not a promise, not a documented feature, but a function of the current implementation. It could happen tomorrow, in theory, that where a = 10000; b = 10000; become the same object as far as "is" is concerned even though today they are different... "is" should only be used in situations where you care about absolute object identity, not *value*.) -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ * P.S. I'm not saying its never right to use "is" outside of The Singletons. Just that its probably not, for most people, what they actually should do in most code. There are numerous counter-examples, of course. Its just a general guideline to follow. Until a need arises that demonstrates otherwise.
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list
