Crash on mypy errors without line numbers

[mvernacc]

I found that incorrect type arguments to numpy types produce mypy errors lines without line numbers, which in turn crash typing_copilot.

Example of incorrect numpy type argument:

def f(z: np.typing.NDArray[int]) -> None:

(should be NDArray[np.intc])

This produces a mypy error line like:

path/to/module.py: error: Type argument "int" of "dtype" must be a subtype of "generic"

Note the above error line does not include a line number, whereas a typical mypy error line does, e.g.: path/to/module.py:12: error: ...

The line-number-less mypy error causes an error in typing_copilot's parsing:

 File "{...}/python3.9/site-packages/typing_copilot/cli.py", line 369, in tighten
    errors = get_mypy_errors_from_completed_process(completed_process)
  File "{...}/python3.9/site-packages/typing_copilot/mypy_runner.py", line 93, in get_mypy_errors_from_completed_process
    return [
  File "{...}/python3.9/site-packages/typing_copilot/mypy_runner.py", line 93, in <listcomp>
    return [
  File "{...}/python3.9/site-packages/typing_copilot/mypy_runner.py", line 95, in <genexpr>
    for value in (MypyError.from_mypy_output_line(error_line) for error_line in error_lines)
  File "{...}/python3.9/site-packages/typing_copilot/mypy_runner.py", line 55, in from_mypy_output_line
    line_number = int(line_num.strip())
ValueError: invalid literal for int() with base 10: 'error'

I am using mypy version 0.971 and typing_copilot version 0.7.0

[obi1kenobi]

Unfortunately, I've given up on maintaining typing_copilot.

Mypy has way too many buggy and weird behaviors (like the "error without line number" here) and is way too inconsistent in those behaviors from version to version. What that means for me is that I spend a ton of energy chasing workarounds to keep typing_copilot working as it did with previous versions of mypy. When I raised these concerns with the Python and mypy maintainers, it was made clear to me that it's not really a problem they plan to do anything about.

I also don't personally use typing_copilot for any of my own projects, since I don't maintain any legacy untyped Python code anymore — all my code is fully type-hinted.

As a result, it isn't practical or realistic for me to maintain this package, either for free in the interest of the community, or for "donation" / "sponsorship"-level payments that some maintainers get.

If a company wants to sign a support contract for typing_copilot, that would be worth considering depending on the exact terms — please ping me if so.

Otherwise, if another maintainer in the Python community wants to step in and maintain typing_copilot, I'd gladly help with the transition.