On 24 February 2018 at 06:00, Chris Angelico wrote:
> I presume it's already too late for 3.7 to change anything to fix this.
>
Yeah, any changes in relation to this would be 3.8+ only.
To answer your previous question about "Wouldn't it be hard to fix this
given the way
On Sat, Feb 24, 2018 at 6:38 AM, Serhiy Storchaka wrote:
> 23.02.18 20:50, Chris Angelico пише:
>>
>> Ignoring backward compatibility, it ought to be possible to (ab)use a
>> stride of zero for this. Calling slice.indices() on something with a
>> stride of zero raises
23.02.18 20:50, Chris Angelico пише:
Ignoring backward compatibility, it ought to be possible to (ab)use a
stride of zero for this. Calling slice.indices() on something with a
stride of zero raises ValueError, so there's no ambiguity. But it
would break code that iterates in a simple and obvious
On Sat, Feb 24, 2018 at 5:24 AM, Chris Barker wrote:
> On Thu, Feb 22, 2018 at 6:21 PM, Nick Coghlan wrote:
>>
>> > (I wonder if the discrepancy is due to some internal interface that
>> > loses
>> > the distinction between None and 1 before the
On 23 February 2018 at 11:51, Guido van Rossum wrote:
> On Thu, Feb 22, 2018 at 2:18 PM, Alexander Heger wrote:
>> But I disagree that there should be no error when it is wrong.
>> *Strides that are not None should always trigger advanced slicing.*
>
> This
On Thu, Feb 22, 2018 at 2:18 PM, Alexander Heger wrote:
> What little documentation I could find, providing a stride on the
> assignment target for a list is supposed to trigger 'advanced slicing'
> causing element-wise replacement - and hence requiring that the source
>
What little documentation I could find, providing a stride on the
assignment target for a list is supposed to trigger 'advanced slicing'
causing element-wise replacement - and hence requiring that the source
iterable has the appropriate number of elements.
>>> a = [0,1,2,3]
>>> a[::2] = [4,5]