<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 24, 2015 at 9:18 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 25 April 2015 at 00:50, Joao S. O. Bueno <<a href="mailto:jsbueno@python.org.br">jsbueno@python.org.br</a>> wrote:<br>
> Since it does not mean anything (as in meaningless) to compare ranges without<br>
> specifying a "key", and since ordering functions in Python do allow a<br>
> "key" - it looks<br>
> like this problem is already resolved, whatever the need:<br>
><br>
>>>> sorted([range(10), range(1,14, 3)], key=len)<br>
> [range(1, 14, 3), range(0, 10)]<br>
>>>> sorted([range(10), range(1,14, 3)], key=max)<br>
> [range(0, 10), range(1, 14, 3)]<br>
>>>> sorted([range(10), range(1,14, 3)], key=min)<br>
> [range(0, 10), range(1, 14, 3)]<br>
<br>
</span>ranges() are actually defined as memory-efficient tuples these days<br>
(<a href="https://docs.python.org/3/library/stdtypes.html#ranges" target="_blank">https://docs.python.org/3/library/stdtypes.html#ranges</a>), and have<br>
supported "==" and "!=" using sequence comparison semantics since 3.3,<br>
so there's a defined natural order for them these days (the ordering<br>
of the equivalent tuples).<br>
<br>
That said, I'm still not sure it makes sense to allow ordering them.<br>
The cases I can think of where it might make sense (such as ordering<br>
graph nodes) would all use an actual tuple instead.<br></blockquote></div><br></div><div class="gmail_extra">Seems everybody has their own view on how range() objects should be ordered. That's one good reason against a builtin ordering.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>