Skip to content

Make slicing of immutable structures return a view instead of a copy #70265

Description

@FilipHaglund
BPO 26077
Nosy @malemburg, @terryjreedy, @vadmium, @serhiy-storchaka, @Vgr255

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2016-01-16.09:48:53.379>
created_at = <Date 2016-01-10.20:45:56.228>
labels = ['interpreter-core', 'performance']
title = 'Make slicing of immutable structures return a view instead of a copy'
updated_at = <Date 2016-01-16.09:48:53.377>
user = 'https://bugs.python.org/FilipHaglund'

bugs.python.org fields:

activity = <Date 2016-01-16.09:48:53.377>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2016-01-16.09:48:53.379>
closer = 'serhiy.storchaka'
components = ['Interpreter Core']
creation = <Date 2016-01-10.20:45:56.228>
creator = 'Filip Haglund'
dependencies = []
files = []
hgrepos = []
issue_num = 26077
keywords = []
message_count = 6.0
messages = ['257937', '257939', '257942', '257952', '258374', '258375']
nosy_count = 6.0
nosy_names = ['lemburg', 'terry.reedy', 'martin.panter', 'serhiy.storchaka', 'abarry', 'Filip Haglund']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue26077'
versions = ['Python 3.6']

Activity

  1. FilipHaglund commented on Jan 10, 2016

    FilipHaglundmannequin
    MannequinAuthor

    Slicing tuples returns a copy, which is O(n) time. This could be O(1) since tuples are immutable, by just pointing to the same data.

    This probably applies to other immutable structures as well, such as strings.

  2. Vgr255 commented on Jan 10, 2016

    Vgr255mannequin
    Mannequin

    This is an interesting idea, +1 from me. Do you want to submit a patch?

  3. vadmium commented on Jan 10, 2016

    @vadmium
    Member

    I think which technique (copy or view) is better depends on the situation. If you are making a large temporary slice, a view may be more efficient. But if you are making a long-term slice and don’t need the original any more, a copy would allow the original memory to be freed early.

    Do you have any use cases? You can already get a kind of slice view into bytes etc by using memoryview().

  4. malemburg commented on Jan 11, 2016

    @malemburg
    Member

    While it's theoretically possible, there's a reason why we haven't done this in the past: we don't want to keep the possibly large original object alive when using a slice.

    For buffer interface types, you can already use memoryview to get a view in case you need this.

    In most other cases, it's better to work with indexes into the original object rather than views on the data.

  5. terryjreedy commented on Jan 16, 2016

    @terryjreedy
    Member

    Proposals for strings views have be rejected precisely because of the keep-alive effect.

    I do not remember if tuples were explicitly part of earlier discussions. One could make the argument that million-item tuples, and especially slicing thereof is rarer than the same for strings. On the other hand, copying short slices of short to medium tuples is not a big deal.

    Because of previous discussions, I think this issue should be either closed or suspended for python-ideas discussion.

  6. serhiy-storchaka commented on Jan 16, 2016

    @serhiy-storchaka
    Member

    The support of sharing a content between different tuples requires changing the structure of the tuple object, allocating additional block for every tuple, adding a level of indirection and reference counting. This will increase memory consumption, creating and access time for all tuples. All this is critically important for Python interpreter. I think this idea has no a chance.

  7. transferred this issue fromon Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    interpreter-core(Objects, Python, Grammar, and Parser dirs)performancePerformance or resource usage

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions