On 08.08.20 05:48, David Mertz wrote:
On Fri, Aug 7, 2020, 6:03 PM Paul Moore <firstname.lastname@example.org mailto:email@example.com> wrote:
> x: int[0:] # any ints greater than or equal to zero would match, others would fail > x: int[:101] # any ints less than 101 match > x: int[0:101:2] # even less than 101 I suspect the biggest issue with this is that it's likely to be extremely hard (given the dynamic nature of Python) to check such type assertions statically.
Yes, it's hard in the sense that it would require solving the halting problem.
How is it any more difficult than already existing type checks? The proposal talks about type hints for static type analysis and hence implies using literals for the slices. There's no dynamic nature to it. You can define `int[x]` to be a subtype of `int[y]` if the numbers defined by `x` are a subset of those defined by `y`.
Referring to one of the examples including `random.randint`:
def foo(x: int[0:11]): pass
Regarding static type analysis, the only information about `random.randint` is that it returns an `int` and hence this should be an error. If you want to use it that way, you'd have to manually cast the value:
foo(typing.cast(int[0:11], random.randint(0, 10)))
This of course raises questions about the usefulness of the feature.
By the way, I would find it more intuitive if the `stop` boundary was included in the interval, i.e. `int[0:10]` means all the integer numbers from 0 to 10 (including 10). I don't think that conflicts with the current notion of slices since they always indicate a position in the sequence, not the values directly (then `int[0:10]` would mean "the first 10 integer numbers", but where do they even start?).