Почему срезы в Python 3 по-прежнему копируют, а не представления?

Как я только сейчас заметил, прокомментировав этот ответ , срезы в Python 3 возвращают мелкие копии всего, что они нарезают, а не представления. Почему это все еще так? Даже если оставить в стороне использование представлений, а не копий для нарезки в numpy, тот факт, что dict.keys , dict.values ​​ и dict.items все возвращают представления в Python 3 и то, что существует множество других аспектов Python 3, направленных на более широкое использование итераторов, заставляет думать, что было бы движение к тому, чтобы срезы стали похожими. itertools действительно имеет функцию islice , которая создает итерационные срезы, но она более ограничена, чем обычное срезы, и не предоставляет функциональные возможности просмотра в соответствии с dict.keys или dict.values ​​.

А также тот факт, что вы можете использовать присвоение срезов для изменения исходного списка, но срезы сами являются копиями, а не представлениями,является противоречивым аспектом языка и кажется, что он нарушает несколько принципов, проиллюстрированных в Дзен Python .

То есть факт, что вы можете делать

>>> a = [1, 2, 3, 4, 5]
>>> a[::2] = [0, 0, 0]
>>> a
[0, 2, 0, 4, 0]

Но не

>>> a = [1, 2, 3, 4, 5]
>>> a[::2][0] = 0
>>> a
[0, 2, 3, 4, 5]

или что-то в этом роде вроде

>>> a = [1, 2, 3, 4, 5]
>>> b = a[::2]
>>> b
view(a[::2] -> [1, 3, 5])   # numpy doesn't explicitly state that its slices are views, but it would probably be a good idea to do it in some way for regular Python
>>> b[0] = 0
>>> b
view(a[::2] -> [0, 3, 5])
>>> a
[0, 2, 3, 4, 5]

Кажется несколько произвольным / нежелательным.

Мне известно о http://www.python.org/dev/peps/pep-3099/ и о части, где написано: и расширенные срезы не исчезнут (даже если API __ getslice __ и __ setslice __ ] могут быть заменены) и не будут возвращать представления для стандартных типов объектов », но связанное обсуждение обеспечивает нет упоминания о том, почему было принято решение о нарезке просмотров; на самом деле, большинство комментариев к этому конкретному предложению из предложений, перечисленных в исходном сообщении, казалось, были положительными.

Что помешало реализовать нечто подобное в Python 3.0, который был специально разработан, чтобы не быть строго обратным -совместим с Python 2.x и, следовательно, было бы лучшим временем для реализации такого изменения в дизайне, и есть ли что-нибудь, что может помешать этому в будущих версиях Python?