The 'is' operator and check-code

Masklinn masklinn at masklinn.net
Tue Nov 16 14:00:17 CST 2010


On 2010-11-16, at 20:40 , Matt Mackall wrote:
> I'm throwing this out in case any Python experts have opinions.
> 
> The 'is' operator is used in a bunch of places as a synonym for ==. This
> happens to work with short strings and small integers (0 to 256) in
> CPython, but that's by no means guaranteed by the language, so there are
> places where we're just getting lucky.

There could also be places where the original writer actually wanted to test for identity aren't there? The 5th match for instance is against `type(foo)`, so it's checking for type equality, and each class should be unique in the system so using identity testing for that seems perfectly sensible, unless you want to include subtypes (likewise for errno.ENOENT or _GLOBAL_DEFAULT_TIMEOUT (I checked the code, the latter is actually an instance of `object()` and used as a special value, so no reason to test for equality) which are "opaque" constants)

On the other hand, the following 3 tests (as well as the second half of the 4th) are crummy, there are already names for the types of 1, '', [] and False (though there is none for type(None), unless you want to import types).

The last match seems to be an other place where identity testing makes sense (or doesn't shock me anyway), `i` is a ready readable object (returned by select), either it's the one being checked for (identity-wise) or it's not, the only things you'd be doing by replacing that with an equality test would be make the code less readable (IMO) and add a pointless level of indirection.

I can definitely see there would be places where we're just "getting lucky" and dodging the bullet due to CPython's interning, but I don't think a blanket forbidding of `is` makes sense.


More information about the Mercurial-devel mailing list