Is this efficient? I was under the impression (which is likely inaccurate, because I'm no expert on Python) that range returned a generator or a list outright, making this an O(n) operation.
You're correct. It returns a list from from [a, b), but it's just another example of some expressive (albeit computationally inefficient) notation Python has.
Edit: I take that back. Here's a section from Python's range() documentation:
> The advantage of the range type over a regular list or tuple is that a range object will always take the same (small) amount of memory, no matter the size of the range it represents (as it only stores the start, stop and step values, calculating individual items and subranges as needed).
No, what the docs say is that range is a generator. It never stores the entire list of values, but it does iterate through all the numbers, spitting them out one by one (hence it uses O(1) memory, but O(n) computation).
Equivalent pseudocode:
function in_range(x, a, b):
for i=a; i<b; i++:
if x == i return true
return false
That... has nothing to do with nemo1618's wish. The python statement 2 <= x < 4 is not a statement about x being within a particular range; it's just as valid to say 2 <= x > 4.
Nobody would ever purposefully write 2 <= x > 4 … it's a bug. Maybe if the bounds on the example were variable.
But the point of being able to collapse a < b and b < c into a < b < c is there to make ranges easier to notate/read. That's seems to be nemo's wish. (Though perhaps he wishes the range to be completely separate, e.g., in the psuedosyntax `b in [1, 3)`.)
I don't think I've ever seen it actually used for anything else, and I would in advocate against it, in code review.
> I don't think I've ever seen it actually used for anything else, and I would in advocate against it, in code review.
Yes, this would be a terrible practice. But that's what Python offers. The desire to express that a variable's value lies within a range is very common, and is presumably the reason for Python's bad choice. But that doesn't make Python's syntax a good response to the desire. The syntax expresses a conceptual mess; you're relying on people only using a tiny subset of what's there.
Contrast lisp, where you actually can express the concept of a range, as (< lowBound variable highBound). Unfortunately, that won't allow you to mix soft bounds with strict bounds. But it's vastly better than Python's approach.
Contrast Ruby, which offers almost every convenience in ranges, including literal notations, that you could ask for.