On Fri, Apr 11, 2008 at 2:45 PM, Brad Miller <report@bugs.python.org> wrote:
..
>  My question is how does this get resolved.  When I posted this idea to
>  python-dev Guido suggested an approach. Nobody else expressed an opinion
>  so after waiting a few days I took Guido's suggestion and implemented a
>  patch.  Now there are objections.
>

My -1 vote is not a veto by any means.  It us ultimately up to Guido
to accept or reject your patch.  I am actually willing to change my
vote to -0.  I cannot recall ever using either str(..) or print on a
range object, so this change will not affect me while I still believe
it will not solve your problem either.

>  Other than some mild frustration at having invested a fair amount of
>  time in producing my first python patch

This happens a lot.  Oftentimes proposals are not even considered
without a working patch.  I hope writing the patch and receiving
Martin's comments on your code was a valuable experience in itself
even if your patch does not get accepted.

> I am also in the middle of
>  editing a textbook that will come out this fall.  my intention is to
>  have this book be 3.0 compatible.  So it would be nice for me to have
>  some clarity on the direction this will go.

I would suggest considering a custom displayhook approach. You can
write a custom displayhook that will print range(..), {}.keys(),
{}.values() etc in a student-friendly way.   I believe a module
installing such display hook can be included in the standard library.
In addition to iterable's display problem such a hook can limit the
amount of output when displaying long lists, insert smart line breaks
etc.  For a textbook, you can instruct the readers to download your
code and import a custom module before trying the examples.  This is
likely to make your textbook more future-proof because you will be
able to update your displayhook code as python changes.