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