[PATCH] cleanup: use x in (a, b) instead of x == a or x == b

Masklinn masklinn at masklinn.net
Thu Sep 23 04:56:56 CDT 2010


On 2010-09-23, at 13:24 , Martin Geisler wrote:
> Brodie Rao <brodie at bitheap.org> writes:
>> # HG changeset patch
>> # User Brodie Rao <brodie at bitheap.org>
>> # Date 1285218151 18000
>> # Node ID a9641ee7e37cf6da972ef07e9c8992316587c51a
>> # Parent  f1e8d6f6e682a74a135ba6509b2de26cc8172046
>> cleanup: use x in (a, b) instead of x == a or x == b
> 
> I believe I tested this at some point using timeit and found that the
> longer form is faster. Did you test is too?

Unless the potentially containing sequence is cached, it probably won't be faster. But in cases where performance on the order of a fraction of a nanosecond per call[0] is not a very important matter, I think the readability and DRY of the `in` form is preferable to the double-eq. YMMV

[0] ran a timeit for a literal 2-tuple `in` of small integers, using timeit.Timer.repeat(repeat=10) and taking the min(), on a 2010 15" MBP using system Python (2.6.1, 2.4GHz Intel i5, 8GB RAM).

In the case where the searched item is the first of the sequence (or tests), the equals wins out by 0.0728s to 0.0783s (+7.5%), in the case where the searched item is not in the sequence (or tests), the equals wins out by 0.122s to 0.134s (+10.1%).

Of course the default repeat is also 1000000 calls, so each replacement is worth about 0.00000001s, or 10 nanoseconds, worst case. Unless it's in a tight loop, I don't think it's going to matter much.

Again, YMMV.


More information about the Mercurial-devel mailing list