[Python-ideas] More useful slices

[Todd]

On Feb 1, 2015 9:48 PM, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
>
> On Mon, 2 Feb 2015 07:38:52 +1100
> Chris Angelico <rosuav at gmail.com> wrote:
> > On Mon, Feb 2, 2015 at 5:13 AM, Thomas Kluyver <thomas at kluyver.me.uk>
wrote:
> > > Iterating over a slice object would work like you were lazily taking
that
> > > slice from itertools.count() - i.e. iter(a:b:c) would be equivalent to
> > > islice(count(), a, b, c). This would also mean that (3:) would have a
> > > logical meaning without having to modify range objects to support an
> > > optional upper bound. I don't see any logical way to iterate over a
slice
> > > defined with negative numbers (e.g. (-4:)), so presumably iter(-4:)
would
> > > raise an exception.
> >
> > If you're going to start defining things in terms of
> > itertools.count(), I'd prefer to first permit a range object to have
> > an infinite upper bound, and then define everything in terms of a
> > sliced range - range objects already support clean slicing.
> >
> > Is there any particular reason for range objects to disallow infinite
> > bounds, or is it just that nobody's needed it?
>
> If the platform's Py_ssize_t type is large enough to represente
> positive infinites, then you probably could support infinite range
> objects.
>

Or you could just make a special case if the upper bound is None.  The
question is what would happen if you tried to get the len() of such a
range.  An exception?  -1? None?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150201/9a612b1c/attachment.html>