On Mon, Oct 28, 2013 at 10:49 AM, Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
On 28 October 2013 13:57, Brett Cannon <brett@python.org> wrote:
>
> On Sun, Oct 27, 2013 at 7:20 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
>>
>> On Sun, 27 Oct 2013 16:56:34 -0500
>> Tim Peters <tim.peters@gmail.com> wrote:
>> > [Guido]
>> > > I wouldn't take out negative strides completely, but I might consider
>> > > deprecating lower and upper bounds other than None (== missing). So
>> > > a[::-1]
>> > > would still work, and a[None:None:-1] would be a verbose way of
>> > > spelling the
>> > > same,
>> >
>> > Happy idea.
>> >
>> > > but a[-1:-6:-1] would be deprecated.
>> >
>> > Not sure I've _ever_ seen that in real life.
>>
>> If it's never seen in real life, then there's probably no urge to
>> deprecate it and later replace it with a new thing, IMHO.
>
> I think there is to minimize even the chance someone has done something like
> this since it's so wonky. We all know someone has somewhere in code out in
> the world.

Are you saying that any code that depends on the current behaviour is
"wonky" and therefore doesn't properly deserve continued support?

I'm saying the current semantics of how the strides work are wonky and we should fix it so valid code has to jump through less hoops to get the semantics they would expect/want.
 

I know I have private (numpy-based) code that depends on this
behaviour. There's nothing wonky about me choosing the limits that I
currently need to in order to get the correct slice.

Sure, all I'm saying is that you probably had to mentally work through more to get the right semantics you wanted compared to if this was changed the way Guido and Tim are suggesting.
 

I think that the numpy mailing lists should be consulted before any
decisions are made. As Antoine says: if you've never noticed this
behaviour before then it obviously doesn't matter to you that much so
why the rush to deprecate it?

I'm not saying not to talk to them, but I also don't think we should necessarily not change it because no one uses it either. If it's wide spread then sure, we just live with it. It's always a balancing act of fixing for future code vs. pain of current code. I'm just saying we shouldn't dismiss changing this out of hand because you are so far the only person who has relied on this.

As for the rush, it's because 3.4b1 is approaching and if this slips to 3.5 that's 1.5 years of deprecation time lost for something that doesn't have a syntactic break to help you discover the change in semantics.
 

> +1 on doing a deprecation in 3.4.

-1 on any deprecation without a clear plan for a better syntax. Simply
changing the semantics of the current syntax would bring in who knows
how many off-by-one errors for virtually no benefit.

The deprecation would be in there from now until Python 4 so it wouldn't be sudden (remember that we are on a roughly 18 month release cycle, so if this went into 3.4 that's 7.5 years until this changes in Python 4). And there's already a future-compatible way to change your code to get the same results in the end that just require more explicit steps/code.
 
-Brett