News for hackers. Stuff that matters.
Re:A Failed Experiment with Python Type Annotations by Deimorz on Tuesday June 11, 2019 @05:09PM (#20159563)
The first issue is fixed by just using a string. Yes, you can't do Sequence[Node], but you can do Sequence["Node"].

The docs talk about this here ("class name forward references"): https://mypy.readthedocs.io/en/stable/kinds_of_types.html#cl...

Re:A Failed Experiment with Python Type Annotations by rcfox on Tuesday June 11, 2019 @05:25PM (#20159683)
For Python 3.7, you can do:

    from __future__ import annotations
This will defer the parsing of annotations until after the file has been parsed, allowing you to use the actual symbol instead of a string.
Re:A Failed Experiment with Python Type Annotations by anentropic on Wednesday June 12, 2019 @06:33AM (#20163251)
TIL!
Re:A Failed Experiment with Python Type Annotations by BurningFrog on Wednesday June 12, 2019 @12:43AM (#20161825)
OK, that works, but it does seem dumb, or even deliberately obtuse.

The language could just as well recognize Node as it recognizes 'Node', but instead it given as a burden for the human programmer to handle.

Is it maybe because mypy is not really part of the Python language, and can't really make changes to it?

Re:A Failed Experiment with Python Type Annotations by _ZeD_ on Wednesday June 12, 2019 @01:24AM (#20161993)
This is not mypy, it's "python-the-language": the annotations are values, and, in this case, the method annotations are evaluated when encountered - which is before the end of the class. So you are trying to use a value still not defined. It's like doing something like

    def foo() -> Bar:
       ...

    class Bar:
       ...
obviously the python interpreter cannot find a "Bar" definition during the parsing of the foo function
Re:A Failed Experiment with Python Type Annotations by BurningFrog on Friday June 14, 2019 @12:18PM (#20184192)
You're saying this is how the language works.

I'm saying the language could work differently.

The case of referring to a class inside its definition is quite different from your "Bar" case. The thing referred to is already declared, it's just not fully defined yet.

There is no logical reason I can see making it impossible for Python to honor the obvious intention of the programmer here. It seems it has just chosen not to do so. Though I'll admit I haven't thought through every weird corner case :)

Re:A Failed Experiment with Python Type Annotations by Deimorz on Wednesday June 12, 2019 @02:49AM (#20162342)
PEP 563 is intended to resolve it: https://www.python.org/dev/peps/pep-0563/

As rcfox said, you can already enable this behavior, and it will be included in Python 4.0.

Re:A Failed Experiment with Python Type Annotations by shakna on Wednesday June 12, 2019 @01:16AM (#20161956)
The language will recognise it in a future version by default, or a from future import can be used now.

mypy isn't behind (here), it's ahead.

Re:A Failed Experiment with Python Type Annotations by mortoray on Tuesday June 11, 2019 @05:10PM (#20159575)
Great!
Re:A Failed Experiment with Python Type Annotations by Deimorz on Tuesday June 11, 2019 @05:19PM (#20159638)
The second issue is a bit of a judgment call too, I think. If the types were inferred you could end up with errors that you're not able to see because inferred types end up compatible. Personally, I think I'd rather write them manually so that I'm validating whether the method actually matches what it was intended to return.

I can't find a more authoritative source right now, but I also remember seeing the same thing that this SO answer says - that it was a deliberate choice not to do this so that people could incrementally add type annotations: https://stackoverflow.com/a/38775381

There are also some separate tools that can infer and generate the annotations for you. I haven't tried them personally, but the mypy docs recommends MonkeyType: https://mypy.readthedocs.io/en/stable/existing_code.html#aut...