[Python-ideas] More useful slices

[Nick Coghlan]

On 2 Feb 2015 21:00, "Chris Angelico" <rosuav at gmail.com> wrote:
>
> On Mon, Feb 2, 2015 at 9:26 PM, Todd <toddrjen at gmail.com> wrote:
> > First, it wouldn't be a replacement.  The existing range syntax would
still
> > exist.
> >
> > But the reason it is beneficial is the same reason we have [a, b, c] for
> > list, {a:1, b:2, c:3} for dicts, {a, b, c} for sets, and (a, b, c) for
> > tuples.  It is more compact way to create a commonly-used data
structure.
> >
> > And I wouldn't consider it any more cryptic than any other literal we
have.
>
> Considering the single most common use of ranges, let's see how a for
> loop would look:
>
> for i in 1:10:
>     pass
>
> Is that nastily cryptic, or beautifully clean? I'm inclined toward the
> former, but could be persuaded.

Some additional historical context, found while looking for range literal
notations in other languages: PEP 204 is a previously rejected proposal for
range literals (https://www.python.org/dev/peps/pep-0204/)

If you'd like to propose a range literal, you may be better off steering
clear of slice notation and instead look to other languages like Ruby or
Haskell for inspiration (slice notation may still be useful for appending a
step to the range definition).

Such an idea will likely still be rejected in the absence of compelling use
cases though, especially as direct iteration over a container or using the
enumerate builtin is often going to be superior to creating a range object.
That makes it very difficult to justify the cost of invalidating all of the
existing documentation on how to create ranges in Python.

Regards,
Nick.

>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150202/c9430030/attachment.html>