Hacker News Reader

Comment by nemetroid | Hacker News Reader

> Another kind of clean up comes in PEP 585 ("Type Hinting Generics In Standard Collections"). It will allow the removal of a parallel set of type aliases maintained in the typing module in order to support generic types. For example, the typing.List type will no longer be needed to support annotations like "dict[str, list[int]]" (i.e.. a dictionary with string keys and values that are lists of integers).

I think this will go a long way toward making type annotations feel less like a tacked-on feature.

View on HN

Looking "back" now, it never occurred to me that importing List when there is list is particularly strange. Now it sticks out sorely. Very glad this change is happening.

That's because we're conditioned to think of constructors as functions rather than as types. I think that's not that odd honestly but I do see how counterintuitive it is for people that don't work much in typed languages. I'm not a Haskellite but there you can clearly see the distinction when defining/instantiating sum types (where the type and data constructor live in different namespaces).

There have been so many improvements in the typing area, I wish they'd waited a while to get it right.

I think getting them out there has already helped the ecosystem, both in terms of using the types to make working in python better, and in terms of figuring out what the typing system should really look like. This is the next iteration, and I think it's going in the right direction, so I don't really want to criticize the devs for it.

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.

> 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.

technically, 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

Thank 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.)

> 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 ;)

Reply on news.ycombinator.com