The analog of ‘i in range(5, 15)’ can be created, something like inrange() named, which expects 2-3 arguments and returns True or False.
The first argument is the number.
If only 2 arguments are set, then the range will be from 0 to the second argument.
If 3 arguments are set, then the range will be from second to the third argument.
Examples for use: if inrange(7, 5, 15): print(“Yes“)
if inrange(7, 15): print(“Yes“)
Suggestion update:
The example inrange(7.0, 5, 15) is more intuitive.
The name between(7.0, 5, 15) seems more appropriate than inrange(7.0, 5, 15).
Nothing is wrong with i in range(5, 15) - It’s perfectly valid Python.
The motivation for inrange() is semantic clarity: it acts as a boolean predicate that clearly communicates a bounds check.
For example, inrange(x, min, max) can be more expressive in validation logic, configuration checks, or APIs, where the concept is “range checking” rather than iteration.
To me a in range(b, c) communicates the intent of a bounds check on a much more clearly than inrange(a, b, c), which would leave me guessing if it means a in range(b, c), c in range(a, b) or even b in range(a, c) upon reading the code for the first time.
You can trivially write a wrapper function with your desired specs if that is what you find more readable, but I just don’t think it’s more expressive to most than the status quo.
The max name makes me wonder whether you even mean the equivalent of in range, as the maximum of a set is included. What would inrange(6, 3, 6) return? And why don’t you just use min <= x < max? (Or <= max?)
That’s a matter of opinion, but fortunately, you can define that function yourself for your own benefit You can have things the exact way you want them, without needing anyone else’s approval!
Thanks for sharing your idea. However, to set expectations and possible shorten a lengthy discussion, I project this has zero chance of acceptance.
First, between(a, b, c) has clarity issues itself: It’s not canonically clear which of the arguments is the value and which are the bounds. It’s also not clear whether the borders are included. Even worse, there are legitimate use cases for all combinations of (not) including borders. This would mean you need four functions or additional parameters like between(a, b, c, include_left=True, include_right=False) which will destroy any potential readability advantage.
Second, the readability advantage is very subjective. I can see that many people will regard a < val < b as more readable compared to between(val, a, b). Also the negated version doesn’t change that: not (a < val < b) vs. not between(val, a, b).
Python strongly prefers “one way to do it” and there are very high bars for introducing new stdlib functions or even builtins. I can see no way how any interpretation/variation of the two aforementioned points can overcome that bar.
You can have things the exact way you want them, without needing anyone else’s approval!