Suggested feature: slice syntax within tuples (or even more generally)?
Hello, Would it be feasible to modify the Python grammar to allow ':' to generate slice objects everywhere rather than just indexers and top-level tuples of indexers? Right now in Py2.7, Py3.3: "obj[:,2]" yields "obj[slice(None),2]" but "obj[(:,1),2]" is an error, instead of "obj[(slice(None), 1), 2]" Also, more generally, you could imagine this working in (almost?) any expression without ambiguity: "a = (1:2)" could yield "a = slice(1,2)" See motivating discussion for this at: https://github.com/pydata/pandas/issues/2866 There might not be very many use cases for this currently outside of pandas, but apparently the grammar was already modified to allow '...' outside indexers and there's probably even fewer valid use cases for that: "e = ..." yields "e = Ellipsis" Would there be any downside to changing the handling of ':' as well? It might even make the grammar simpler, in some ways, since indexers won't have to be treated specially. Let me know if you have any thoughts. Thanks! Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggested feature: slice syntax within tuples (or even more generally)?
> > 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. 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. -Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggested feature: slice syntax within tuples (or even more generally)?
Apparently Travis Oliphant of numpy would like this as well... http://technicaldiscovery.blogspot.com/2011/06/python-proposal-enhancements-i-wish-i.html On Wednesday, February 13, 2013 2:00:15 PM UTC-5, steph...@gmail.com wrote: > Hello, > > > > Would it be feasible to modify the Python grammar to allow ':' to generate > slice objects everywhere rather than just indexers and top-level tuples of > indexers? > > > > Right now in Py2.7, Py3.3: > > "obj[:,2]" yields "obj[slice(None),2]" > > but > > "obj[(:,1),2]" is an error, instead of "obj[(slice(None), 1), 2]" > > > > Also, more generally, you could imagine this working in (almost?) any > expression without ambiguity: > > "a = (1:2)" could yield "a = slice(1,2)" > > > > See motivating discussion for this at: > > https://github.com/pydata/pandas/issues/2866 > > > > There might not be very many use cases for this currently outside of pandas, > but apparently the grammar was already modified to allow '...' outside > indexers and there's probably even fewer valid use cases for that: > > "e = ..." yields "e = Ellipsis" > > > > Would there be any downside to changing the handling of ':' as well? It might > even make the grammar simpler, in some ways, since indexers won't have to be > treated specially. > > > > Let me know if you have any thoughts. > > > > Thanks! > > Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggested feature: slice syntax within tuples (or even more generally)?
> > > >> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggested feature: slice syntax within tuples (or even more generally)?
On Thursday, February 14, 2013 3:03:50 AM UTC-5, Steven D'Aprano wrote: > 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? > > > > http://osdir.com/ml/python.python-3000.devel/2006-05/msg00686.html > > http://mail.python.org/pipermail/python-list/2001-August/094909.html > > > > E.g.: > > > > if x: > > pass > > > > > > Is that intended as "if slice(x, None, None)" with a missing colon, or > > "if x" with colon supplied? I don't mean to argue with Guido, but unless I'm missing something, the former would be a syntax error and the latter would not be, so even if it might be ambiguous in isolation it wouldn't be in context. Isn't this something that could be resolved without requiring a mathematically more complex parser than Python already requires? (i.e. one that corresponds to a more complex minimal automaton). Also, you could easily restrict that ':' cannot be in top-level expressions, so have to be enclosed with either () or [] (so the latter because just a specific case of a more general rule.) > > > > With the addition of one extra letter, you can use slice notation to > > return slice objects: > > > > class SlicerAndDicer: > > def __getitem__(self, item): > > return item > > > > s = SlicerAndDicer() > > > > > > And some examples: > > > > py> s[2::5] > > slice(2, None, 5) > > py> s[::-1] > > slice(None, None, -1) > > py> s[3, 4] > > (3, 4) > > py> s[3, 4:6] > > (3, slice(4, 6, None)) > > py> s[7::, 9] > > (slice(7, None, None), 9) > Hah, yes. I basically wrote that exact example in my reply to Steven at the same time you replied. numpy.s_ is similar (although I think it does some extra work for odd reasons). Anyway this is an okay workaround, but it just seems to highlight the fact that the restriction of using ':' within [] is arbitrary to begin with, since all you're doing is wrapping a function call. Right now, everything which is parsed within f() is also parsed within f[], but the latter is parsing more things just by virtue of the fact that that it's a [] instead of (). To be honest, this feels like more of an artifact of historical evolution than anything else. It just doesn't make much sense create a special syntax for parsing expressions into objects in one particular context but not others when there's nothing special about the underlying object protocol that requires it to be handled separately (and perhaps this was not always the case...I've not been with Python long enough to know the particulars of how this was implemented in the past...) Anyway, thanks for the feedback! - Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggested feature: slice syntax within tuples (or even more generally)?
> Hah, yes. I basically wrote that exact example in my reply to Steven at the > same time you replied. numpy.s_ is similar (although I think it does some > extra work for odd reasons). Oops, this is silly in retrospect...sorry, wasn't looking at the From: line carefully enough and didn't realize I was responding to you again. -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggested feature: slice syntax within tuples (or even more generally)?
> > You can't just allow ':' to generate slice objects everwhere without > > introducing ambiguity, so your proposal would have to be to allow slice > > objects in wider but still restricted contexts. Yeah, I mentioned that in a follow-up. I'm pretty sure of just allowing it within [] and () would work, though, and still be a pretty consistent/simple grammar. This would also remove Steven's (i.e. Guido's) objection that about if x: This would still preserves the main benefit of allowing you to succinctly create slices in any context you need an expression in, because you can always add () around any expression. -Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Suggested feature: slice syntax within tuples (or even more generally)?
On Thursday, February 14, 2013 1:58:06 PM UTC-5, Ian wrote:
>
> That's not ambiguous, because the former is simply invalid syntax.
>
> However, consider the following.
>
>
>
> if 1: 2:
>
>
>
> That could be either a one-line if statement where the condition is 1
>
> and the body is slice(2, None), or it could be the beginning of a
>
> multi-line if block where the condition is slice(1, 2). If the parser
>
> sees that, should it expect the next line to be indented or not? If
>
> it relies on indentation to determine this, then it loses some ability
>
> to warn the user of incorrect indentation.
>
>
>
> Then we have dictionary literals:
>
>
>
> {1:2:3}
>
>
>
> Should that be read as dict([(slice(1, 2), 3)]) or dict([(1, slice(2,
>
> 3))])? Or even set([slice(1, 2, 3)])?
>
Restricting this to within the top level of ()-enclosed expressions would be
sufficient to eliminate all ambiguities, though, right? Basically all that
needs to change is for expressions within '()' to be parsed identically as are
currently parsed in '[]'.
-Stephen
--
http://mail.python.org/mailman/listinfo/python-list
