Make range objects orderable
I propose adding the ability to compare range objects using methods (e.g. range.issubrange) and/or regular operators. Example:
In [56]: range(0, 10, 3).issubrange(range(10)) Out[56]: True
In [57]: range(0, 10, 3) <= range(10) Out[57]: True
In [58]: range(10) <= range(0, 10, 3) Out[58]: False
I'll write a patch if you decide that this idea is worth implementing.
On Thu, Apr 23, 2015 at 5:21 PM, Riley Banks waultah@gmail.com wrote:
I propose adding the ability to compare range objects using methods (e.g. range.issubrange) and/or regular operators. Example:
In [56]: range(0, 10, 3).issubrange(range(10)) Out[56]: True In [57]: range(0, 10, 3) <= range(10) Out[57]: True In [58]: range(10) <= range(0, 10, 3) Out[58]: FalseI'll write a patch if you decide that this idea is worth implementing.
Could you give some examples of how or when this is necessary and why you need it?
Cheers, Ian
f you don't mind converting to a set (can alter the order but the original range can be easily reproduced) then print set(range(0, 10, 3)).issubset(set(range(10)))
On 4/23/15, Ian Cordasco graffatcolmingov@gmail.com wrote:
On Thu, Apr 23, 2015 at 5:21 PM, Riley Banks waultah@gmail.com wrote:
I propose adding the ability to compare range objects using methods (e.g. range.issubrange) and/or regular operators. Example:
In [56]: range(0, 10, 3).issubrange(range(10)) Out[56]: True In [57]: range(0, 10, 3) <= range(10) Out[57]: True In [58]: range(10) <= range(0, 10, 3) Out[58]: FalseI'll write a patch if you decide that this idea is worth implementing.
Could you give some examples of how or when this is necessary and why you need it?
Cheers, Ian
On 04/23, Riley Banks wrote:
I propose adding the ability to compare range objects using methods (e.g. range.issubrange) and/or regular operators. Example:
In [56]: range(0, 10, 3).issubrange(range(10)) Out[56]: True In [57]: range(0, 10, 3) <= range(10) Out[57]: True In [58]: range(10) <= range(0, 10, 3) Out[58]: False
I seem to recall orderable ranges being rejected before. For example, is less-than, or subrange, dependent on the values themselves, or on the lowest and highest values, or on the start and end value, or ...
In other words, given:
a = range(11) b = range(12, step=3)
is a < b, or b < a? Why?
-- ~Ethan~
On 2015-04-24 01:15, Ethan Furman wrote:
On 04/23, Riley Banks wrote:
I propose adding the ability to compare range objects using methods (e.g. range.issubrange) and/or regular operators. Example:
In [56]: range(0, 10, 3).issubrange(range(10)) Out[56]: True In [57]: range(0, 10, 3) <= range(10) Out[57]: True In [58]: range(10) <= range(0, 10, 3) Out[58]: FalseI seem to recall orderable ranges being rejected before. For example, is less-than, or subrange, dependent on the values themselves, or on the lowest and highest values, or on the start and end value, or ...
In other words, given:
a = range(11) b = range(12, step=3)
is a < b, or b < a? Why?
It could be functionally equivalent to list(a) < list(b).
On 4/23/2015 8:31 PM, MRAB wrote:
On 2015-04-24 01:15, Ethan Furman wrote:
On 04/23, Riley Banks wrote:
I propose adding the ability to compare range objects using methods (e.g. range.issubrange) and/or regular operators. Example:
In [56]: range(0, 10, 3).issubrange(range(10)) Out[56]: True In [57]: range(0, 10, 3) <= range(10) Out[57]: True
This was not obvious to me. Ranges are not sets.
In [58]: range(10) <= range(0, 10, 3) Out[58]: FalseI seem to recall orderable ranges being rejected before. For example, is less-than, or subrange, dependent on the values themselves, or on the lowest and highest values, or on the start and end value, or ...
I remember the same. There is no intuitive answer. Let us not rehash this again.
In other words, given:
a = range(11) b = range(12, step=3)
is a < b, or b < a? Why?
It could be functionally equivalent to list(a) < list(b).
For range(0, 10, 3) <= range(10), this would give the opposite answer as the set interpretation.
Sorry - it looks like Guido's time machine have been there.
Since it does not mean anything (as in meaningless) to compare ranges without specifying a "key", and since ordering functions in Python do allow a "key" - it looks like this problem is already resolved, whatever the need:
sorted([range(10), range(1,14, 3)], key=len)
[range(1, 14, 3), range(0, 10)]
sorted([range(10), range(1,14, 3)], key=max)
[range(0, 10), range(1, 14, 3)]
sorted([range(10), range(1,14, 3)], key=min)
[range(0, 10), range(1, 14, 3)]
On 23 April 2015 at 22:11, Terry Reedy tjreedy@udel.edu wrote:
On 4/23/2015 8:31 PM, MRAB wrote:
On 2015-04-24 01:15, Ethan Furman wrote:
On 04/23, Riley Banks wrote:
I propose adding the ability to compare range objects using methods (e.g. range.issubrange) and/or regular operators. Example:
In [56]: range(0, 10, 3).issubrange(range(10)) Out[56]: True In [57]: range(0, 10, 3) <= range(10) Out[57]: TrueThis was not obvious to me. Ranges are not sets.
In [58]: range(10) <= range(0, 10, 3) Out[58]: FalseI seem to recall orderable ranges being rejected before. For example, is less-than, or subrange, dependent on the values themselves, or on the lowest and highest values, or on the start and end value, or ...
I remember the same. There is no intuitive answer. Let us not rehash this again.
In other words, given:
a = range(11) b = range(12, step=3)
is a < b, or b < a? Why?
It could be functionally equivalent to list(a) < list(b).
For range(0, 10, 3) <= range(10), this would give the opposite answer as the set interpretation.
-- Terry Jan Reedy
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 25 April 2015 at 00:50, Joao S. O. Bueno jsbueno@python.org.br wrote:
Since it does not mean anything (as in meaningless) to compare ranges without specifying a "key", and since ordering functions in Python do allow a "key" - it looks like this problem is already resolved, whatever the need:
sorted([range(10), range(1,14, 3)], key=len)
[range(1, 14, 3), range(0, 10)]
sorted([range(10), range(1,14, 3)], key=max)
[range(0, 10), range(1, 14, 3)]
sorted([range(10), range(1,14, 3)], key=min)
[range(0, 10), range(1, 14, 3)]
ranges() are actually defined as memory-efficient tuples these days (https://docs.python.org/3/library/stdtypes.html#ranges), and have supported "==" and "!=" using sequence comparison semantics since 3.3, so there's a defined natural order for them these days (the ordering of the equivalent tuples).
That said, I'm still not sure it makes sense to allow ordering them. The cases I can think of where it might make sense (such as ordering graph nodes) would all use an actual tuple instead.
Cheers, Nick.
On Fri, Apr 24, 2015 at 9:18 PM, Nick Coghlan ncoghlan@gmail.com wrote:
On 25 April 2015 at 00:50, Joao S. O. Bueno jsbueno@python.org.br wrote:
Since it does not mean anything (as in meaningless) to compare ranges
without
specifying a "key", and since ordering functions in Python do allow a "key" - it looks like this problem is already resolved, whatever the need:
sorted([range(10), range(1,14, 3)], key=len)
[range(1, 14, 3), range(0, 10)]
sorted([range(10), range(1,14, 3)], key=max)
[range(0, 10), range(1, 14, 3)]
sorted([range(10), range(1,14, 3)], key=min)
[range(0, 10), range(1, 14, 3)]
ranges() are actually defined as memory-efficient tuples these days (https://docs.python.org/3/library/stdtypes.html#ranges), and have supported "==" and "!=" using sequence comparison semantics since 3.3, so there's a defined natural order for them these days (the ordering of the equivalent tuples).
That said, I'm still not sure it makes sense to allow ordering them. The cases I can think of where it might make sense (such as ordering graph nodes) would all use an actual tuple instead.
Seems everybody has their own view on how range() objects should be ordered. That's one good reason against a builtin ordering.
participants (9)
-
David Blaschke -
Ethan Furman -
Guido van Rossum -
Ian Cordasco -
Joao S. O. Bueno -
MRAB -
Nick Coghlan -
Riley Banks -
Terry Reedy