Suggested feature: slice syntax within tuples (or even more generally)?
steve+comp.lang.python at pearwood.info
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 bad...do 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
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 blist[s] # reuse the slice object
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