3 ms·
I'm extremely excited about this. I had been using a short-hand literal-based syntax like [int] for a while, but list[int] is obviously so much better.
by acbart 6y ago
I'm extremely excited about this. I had been using a short-hand literal-based syntax like [int] for a while, but list[int] is obviously so much better.
- Myrmornis 6y ago> I had been using a short-hand literal-based syntax like [int] for a while, Do you mean you'd been using that in comments? Just to be clear, this isn't about ad-hoc syntaxes for use in comments, this is about syntax that parses when used in python code, and which can be used by type-checkers.
- uryga 6y agotechnically, you can use any valid python expression in annotations. [int] {str: int} {'x': float, 'x': float} are all valid python syntax, so e.g. these are all valid: def f(xs: [int]) -> {str: int}: ... def g(x: 1+2+3, y: what('ever')) -> foo / bar: ... it's just that tools like mypy won't be able to use that, because they expect a class or a `typing` type. i'm pretty sure you could even write a mypy plugin that'd interpret `[int]` into `list[int]` etc
- Myrmornis 6y agoThank you. I didn't know that the python grammar was so permissive regarding what goes in the annotation slots. I did wonder whether I was saying something wrong / sticking my neck out because I had a feeling that the person I was replying to knew what they were talking about. In practice though we should probably all write annotations that do work with an existing type checker. False negatives are bad enough in mypy without people writing annotations for non-existent type checkers! (IMO --check-untyped-defs should always be used; mypy is misleading without it.)
- uryga 6y ago> In practice though we should probably all write annotations that do work with an existing type checker. oh, sure! "freeform annotations" that break mypy in a published library should be a punishable offense ;)