Apply similar slicing optimizations as `tuple` and `str` to `range`

[hyperkai]

Bug report

Bug description:

copy.copy() and copy.deepcopy() don't copy a range as shown below:

import copy

v1 = range(5)

v2 = copy.copy(v1)
v2 = copy.deepcopy(v1)

print(v1 is v2)
# True

But slicing copies a range as shown below:

v1 = range(5)

v2 = v1[:]

print(v1 is v2)
# False

Basically, a shallow or deep copy operation with copy.copy(), slicing or copy.deepcopy() doesn't create a copy for an immutable object like a tuple, string or bytes to avoid wasting memory but only slicing copies a range even though copy.copy() and copy.deepcopy() don't copy a range.

CPython versions tested on:

3.12

Operating systems tested on:

Windows

Linked PRs

• gh-139476: Optimize range[:] slice #139556

[picnixz]

range is considered an atomic type and thus copy.copy directly returns it. We could optimize range slicing for this specific usage but I'm not sure it's really worth it. How much do we gain in practice? range creation is fast, and we maintain a free list of ranges as well to speed-up instantiation. Also, range objects are quite cheap in general (equivalent to a 4-uplet of ints).

Changing the (C) code may make it less clear, so I don't think it's worth it. If you provide a patch that still have a clean code, and benchmarks that show that creating many range copies is a bottleneck, then I would be willing to accept this improvement. Otherwise, I'm not sure it's worth it (I never had to copy a range with [:]).

[picnixz]

Closing as not planned because such optimization is not needed and the implementation is not that trivial. See #139556 (comment).