
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)