Suggested feature: slice syntax within tuples (or even more generally)?

Steven D'Aprano steve+comp.lang.python at
Thu Feb 14 08:32:09 CET 2013

On Wed, 13 Feb 2013 21:54:43 -0800, stephenwlin wrote:

>> I believe the idea of slice literals has been rejected.
> That's too you have a link to prior discussion on this and what
> the reasoning was for rejection? There doesn't seem to be any particular
> downside and things would be more consistent with slice syntax allowed
> anywhere.

There's *always* downside to new syntax. The question is, does the 
benefit exceed the downside?

- new syntax requires more complexity in the parser;

- new tests for it;

- more documentation;

- increase in the number of things people have to learn before they can 
read and write Python code;

- takes the language further away from "executable pseudo-code" and 
closer to "line noise";

- somebody has to actually write the code, write the tests, write the 
documentation; and somebody else has to review it; for a chronically 
short-handed dev team where there are hundreds of bugs and feature 
requests in the queue, this is a significant cost.

Now, you might argue that these are all *low* cost, but they're not zero, 
and how do they stack up against the benefits?

What are the benefits of syntactic sugar for slice objects?

Personally, there's not much difference to my eye between:

S = slice
S(1, 20, 3)



so I'm skeptical that the benefit is much greater than the cost, as low 
as that cost may be.

> It would be helpful in other cases as well other than the one linked to,
> since there's good reason to be able to succinctly create and reuse the
> same indexer object multiple times without having to convert everything
> into slice() calls.

I don't quite understand this argument. If you mean that you can do this:

s = (1:2)  # Like slice(1, 2).
print alist[s]
print blist[s]  # reuse the slice object
print clist[s]

you can replace the line s = (1:2) to a call to slice, and still reuse 
the slice object. So I don't understand what the syntactic sugar gains 


More information about the Python-list mailing list