mypy VS typing

how, when mypy itself has only "type: ignore" as a workaround for many scenarios?

here's a list of 41 issues where either the user or the mypy devs are saying "use type: ignore as a workaround for now":

https://github.com/python/mypy/issues?q=is%3Aopen+label%3Afa...

It reminds me of this 5 year old bug in mypy: "int is not a Number?" [1].

[1]: https://github.com/python/mypy/issues/3186

Mypy is an optional static type checker that aims to combine the benefits of dynamic (or “duck”) typing and static typing. The benefits of statically typed code are increased readability and maintainability. For an existing code base here's a guide on how to implement Mypy.

mypy – Optional static typing for Python

You might get some luck by asking it on the mypy repo.

Been looking into it a bit more. I think you're right, it's not supported. Turns out mypy only has very limited support for type hinting metaclasses. This page suggests it may be possible to support this with a mypy plugin, but I'm really not looking to do something that involved. Just wanting to hint an existing API :/ I suppose I could look into tweaking the API to be more hint-able, but I think I'll just accept this piece isn't perfect.

When working with several people on one project, it is very often necessary to use a single style of code design, writing comments, using variable names, etc. In the Python world, we use linters flake8, various formatters (black, yapf, autopep8) and mypy for type checking. How can Dart help meet these challenges?

Since Python 3.5, type annotations can be used for possible static analysis, refactoring, runtime type checking and code generation. An optional static type checker named mypy supports compile-time type checking.

Also, there’s Mypyc.

While yes 26 people liked the idea here: https://github.com/python/typing/issues/193

but looking at relevant issues on GitHub it seems this has been shot down repeatedly. python/typing#18, python/typing#213

See https://github.com/python/typing/issues/256 for a discussion.

Lower bounds are not supported for TypeVars, unfortunately.

Mypy allows that because initial versions of PEP-484 allowed that. This has changed; here's the current wording on the PEP:

> This is no longer the recommended behavior. Type checkers should move towards requiring the optional type to be made explicit.

https://www.python.org/dev/peps/pep-0484/#id29

Dunno, other, larger projects than the one I'm working on seem to run up against this from time to time. (rasa_core, to pick one example from near the top of a Google search; also Telethon, Blender, TensorFlow, Pandas. Guido also filed a bug on the typing module in an early version of Python 3.5 because of unexpected implications of this particular issue, so the problem isn't exactly purely theoretical.) That's aside from the wish for conceptual purity in the call signatures of classes and their subclasses, which is not always and automatically a bad wish to have; and the notion that a language that prides itself on its introspective faculties might want to make introspection of classes from the top of a class hierarchy possible, at least in theory? Perhaps to facility learning about the language and/or visualizing large class hierarchies easily, for instance?

Yeah it's called Type Hinting

How do you define Python? If you include PEP 484 in your definition, surely it must be 'statically typed', otherwise there would be no need for these terms.

Since Python 3.5 (PEP-484), developers can add type annotations to their code. Python's optional static typing improves code comprehension, code completion, program analysis, and more. However, retrofitting type annotations can be a laborious and time-consuming task.