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]: False
I'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]: False
I'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
-- With the simplicity of true nature, there shall be no desire. Without desire, one's original nature will be at peace. And the world will naturally be in accord with the right Way. Tao Te Ching
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]: 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?
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]: 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 ...
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
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]: True
This was not obvious to me. Ranges are not sets.
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 ...
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. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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. -- --Guido van Rossum (python.org/~guido)
participants (9)
-
David Blaschke -
Ethan Furman -
Guido van Rossum -
Ian Cordasco -
Joao S. O. Bueno -
MRAB -
Nick Coghlan -
Riley Banks -
Terry Reedy