incompatible_range_type: Make range() return a non-list iterable

[brandjon]

range() currently returns a list of integers. This takes memory proportional to the size of the range, even though it can easily be represented using just its bounds and step. It's especially bad when used for iteration in a loop that breaks early. We should make range() return a list-like object as in Python 3.

If we take the Python 3 approach, range() would return a completely separate type of sequence from lists and tuples, with observably different behavior on the operations str(), repr(), type(), ==, ordering, +, and slicing.

[c-parsons]

The issue should remain open until we migrate users onto the flag --incompatible_range_type

[laurentlb]

Before switching this flag, please make sure we're happy with the exact semantics (str, repr, operators, etc.).

[laurentlb]

I've tested the implementation. It seems to behave the same as Python3 and https://github.com/google/skylark/.

r = range(7)
print(r)  # range(7)
print(r[2:])  # range(2, 7)
print(r[1:9:2])  # range(1, 7, 2)
print(r[1:5:2])  # range(1, 5, 2)
print(repr(r[1:5:2]))  # range(1, 5, 2)
print(type(r))  # range
# print(r + [6])  # type error (like Python3, unlike Python2)
# print(r * 2)  # type error (like Python3, unlike Python2)

Bug: We should throw an error when comparing range objects:

r < r

Something interesting:

print(range(0, 5, 10) == range(0, 5, 11))

This returns False with the Go implementation; True with both Python3 and Bazel (I suppose it iterates over both ranges?).

Anything else we should test or consider?

[laurentlb]

cc @ttsugriy

I plan to switch the default of incompatible_range_type for Bazel 0.20 (November), unless there's any concern.

[ttsugriy]

@laurentlb, I would be delighted! We've been using it in Buck since it was added to Bazel and haven't had any issues so far :) I hope Bazel users would enjoy it as much as Buck users :)