| commit | 544b97ec296e16e4c96a42a1b81d5dcd841cf232 | [log] [tgz] |
|---|---|---|
| author | Piotr Sawicki <sawickipiotr@outlook.com> | Tue Jan 27 13:56:45 2026 +0100 |
| committer | GitHub <noreply@github.com> | Tue Jan 27 13:56:45 2026 +0100 |
| tree | 7505a434b9ee0a9ae6a0927fc83edcb61048dbb5 | |
| parent | fb506caa4ab5c77f3d888ff74d80ac56a409cda4 [diff] |
[mypyc] Do not emit tracebacks with negative line numbers (#20641) mypyc may add tracebacks in the generated code with line number -1 when the AST expression that generates an error has no line set. This is usually the case for expressions that are not directly linked with a line in the Python code but are generated internally by mypyc, like helper functions generated for `async` functions. These tracebacks become a problem when running a test that calls a compiled function with pytest. The line number ends up being interpreted by Python as `None` instead of an `int` and pytest crashes when [trying to do math on it](https://github.com/pytest-dev/pytest/blob/main/src/_pytest/_code/code.py#L211). So instead of a stack trace pointing to the compiled function we get an internal pytest error which makes debugging more difficult. Changes in this PR ensure that AST nodes that may produce tracebacks have their line numbers set. For AST nodes generated by mypyc this usually means the line number of the function they are associated with, so an internal attribute access node inside a helper function generated for an `async def my_fun()` will have the line number of `my_fun`. I didn't add a specific test for this because getting an exception from an internally generated node means that there is a bug in mypyc that we should fix but I tested it with one such error that I'm working on and pytest no longer crashes. I have also added assertions so that new changes to mypyc don't cause it to generate tracebacks with negative line numbers. For now the assertions are only enabled in tests since there are cases where mypyc emits tracebacks that we don't have tests for, and the new assertions could break compilation that currently succeeds without them. Once we remove all cases where tracebacks with negative line numbers are possible we can enable them by default.
We are always happy to answer questions! Here are some good places to ask them:
If you're just getting started, the documentation and type hints cheat sheet can also help answer questions.
If you think you've found a bug:
To report a bug or request an enhancement:
To discuss a new type system feature:
Mypy is a static type checker for Python.
Type checkers help ensure that you're using variables and functions in your code correctly. With mypy, add type hints (PEP 484) to your Python programs, and mypy will warn you when you use those types incorrectly.
Python is a dynamic language, so usually you'll only see errors in your code when you attempt to run it. Mypy is a static checker, so it finds bugs in your programs without even running them!
Here is a small example to whet your appetite:
number = input("What is your favourite number?") print("It is", number + 1) # error: Unsupported operand types for + ("str" and "int")
Adding type hints for mypy does not interfere with the way your program would otherwise run. Think of type hints as similar to comments! You can always use the Python interpreter to run your code, even if mypy reports errors.
Mypy is designed with gradual typing in mind. This means you can add type hints to your code base slowly and that you can always fall back to dynamic typing when static typing is not convenient.
Mypy has a powerful and easy-to-use type system, supporting features such as type inference, generics, callable types, tuple types, union types, structural subtyping and more. Using mypy will make your programs easier to understand, debug, and maintain.
See the documentation for more examples and information.
In particular, see:
Mypy can be installed using pip:
python3 -m pip install -U mypy
If you want to run the latest version of the code, you can install from the repo directly:
python3 -m pip install -U git+https://github.com/python/mypy.git
Now you can type-check the statically typed parts of a program like this:
mypy PROGRAM
You can always use the Python interpreter to run your statically typed programs, even if mypy reports type errors:
python3 PROGRAM
If you are working with large code bases, you can run mypy in daemon mode, that will give much faster (often sub-second) incremental updates:
dmypy run -- PROGRAM
You can also try mypy in an online playground (developed by Yusuke Miyazaki).
Mypy can be integrated into popular IDEs:
Additional information is available at the web site:
Jump straight to the documentation:
Follow along our changelog at:
https://mypy-lang.blogspot.com/
Help in testing, development, documentation and other tasks is highly appreciated and useful to the project. There are tasks for contributors of all experience levels.
To get started with developing mypy, see CONTRIBUTING.md.
Mypyc uses Python type hints to compile Python modules to faster C extensions. Mypy is itself compiled using mypyc: this makes mypy approximately 4 times faster than if interpreted!
To install an interpreted mypy instead, use:
python3 -m pip install --no-binary mypy -U mypy
To use a compiled version of a development version of mypy, directly install a binary from https://github.com/mypyc/mypy_mypyc-wheels/releases/latest.
To contribute to the mypyc project, check out the issue tracker at https://github.com/mypyc/mypyc