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)