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
