[Python-ideas] List assignment - extended slicing inconsistency

Nick Coghlan ncoghlan at gmail.com
Sat Feb 24 01:03:08 EST 2018


On 24 February 2018 at 06:00, Chris Angelico <rosuav at gmail.com> 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 slice processing works?", whether or not it's tricky depends
more on the internal code structure of any given type implementation than
it does the API that [C]Python exposes for converting a slice definition to
a set of indices given a particular sequence length.

For lists, for example, the code handling that dispatch is in the "list
assign subscript" function, under a "PySlice_Check(item)" branch:
https://github.com/python/cpython/blob/master/Objects/listobject.c#L2775

There's an early return there for the "step == 1" case, but at the point
where we run that check, we still have access to "item", so that early
return can be modified to instead check "((PySliceObject *) item->step ==
Py_None)".

During the deprecation warning period, we'd then *also* add a second
delegation point down where the exception normally gets raised, such that
when "step == 1" we emit the deprecation warning and then call the same
function as the existing early return does. In 3.9+, we'd delete that
additional fallback code.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180224/3c6df5d7/attachment.html>


More information about the Python-ideas mailing list