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

[stephenwlin at gmail.com]

> 
> 
> >> 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
> 
> > anywhere.
> 
> 
> 
> There's *always* downside to new syntax. The question is, does the 
> 
> benefit exceed the downside?
> 
> 
> 

Fair enough points w.r.t with the costs of implementation, etc. I just meant that, from my perspective, it seems like a simplification of the grammar rather than making it more complex, since it just makes ':' work the same way outside of [] as within it, instead of treating [] as a special case. I'm aware there could be some ambiguities with dictionary construction but it should be pretty easy to resolve with precedence rules.

As for making the language more complicated to learn: to be honest, the fact that ':' was treated specially in [] made things more confusing to me until I realized there was a special grammar specifically for that case (since this is not something I would expect coming from other languages). That there would be specific grammar for this case would make more sense if there was something about the __getitem__/__setitem__ protocol that inherently required it, but there isn't really: you're just passing an object to __getitem__ just like you can pass an object to any function, so why would you parse expressions differently in the former case versus the latter? Obviously, this depends on one's individual intuition though, so maybe I'm in the minority here in finding it weird.

> 
> 
> 
> 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)
> 
> 
> 
> versus
> 
> 
> 
> (1:20:3)
> 
> 
> 
> so I'm skeptical that the benefit is much greater than the cost, as low 
> 
> as that cost may be.

But if there's no difference, then why have ':' work specially for '[]' operations at all instead of requiring the user to build slice objects manually all the time? It obviously is a convenient and simpler syntax, and there doesn't seem to be any real reason for the artificial restriction that this happens inside '[]' (and in a shallow manner, so no nested slices or slices within tuples) only.

> 
> 
> 
> 
> 
> > 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 
> 
> you.
> 
> 
> 

Yes, but you can't just directly use what you wrote within '[]' outside of it, and there doesn't seem to be any real technical reason for this except for historical evolution of the language. Obviously isn't not that hard to convert everything to call slice() manually but it can get verbose quickly for complex multidimensional slices cases (which are common in numpy, which is why Travis Oliphant wants this feature as well...)

You can do something hackish like make a dummy object that returns

class Indexer:
    def __getitem__(self, obj):
        return obj

I = Indexer()

s = I[1:2,..,3:4:-1,::-1]

but that seems that seems mostly to highlight the fact that this is an artificial problem to begin with...'[]' just translates to a function call anyway (more or less), so why treat it differently?

Thanks,

-Stephen