HP6632b.check_error_queue raises warning in Py37

[scasagrande]

HP6632b.check_error_queue / hp6632b.py#L471 raises the following warning:

hp6632b.py:471: DeprecationWarning: using non-Enums in containment checks will raise TypeError in Python 3.8

On this line we are doing this:

err in self.ErrorCodes

where err is an int.

This should be changed to:

err in set(item.value for item in self.ErrorCodes)

or we can add a class method to the enum:

@classmethod
def has_value(cls, value):
    return any(value == item.value for item in cls)

We can even do a lazy-cache for this set to avoid regeneration on every HP6632b.check_error_queue call

[scasagrande]

Making use of %timeit, I tried a few solutions, and so far this is the fastest by a decent margin once the cache is built:

@classmethod
def has_value(cls, value):
    if not hasattr(cls, "_value_cache"):
        setattr(cls, "_value_cache", set(item.value for item in cls))
    return value in cls._value_cache

Building the cache, on my laptop, looks to be about 57us

In [24]: %timeit set(item.value for item in ErrorCodes)
56.8 µs ± 1.07 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

A single lookup in the worst case (not in enum) using any has a similar time cost:

In [25]: %timeit any(100 == item.value for item in ErrorCodes)
54.5 µs ± 1.06 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

Where the best case (first item lookup success) is about 2us

In [26]: %timeit any(0 == item.value for item in ErrorCodes)
1.66 µs ± 71.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

These numbers are all pretty small, and I don't feel this would ever be the limiting factor. This would be by far dominated by the instrument communication time to just get the error code. Considering that most lookups will be valid, and probably dominated by the best case, I think I'll just use the any solution.

[scasagrande]

Fixed in PR #201