fix(stdlib/types): FrameType.f_lineno can be None#6769
Conversation
In very rare (error?) cases, f_lineno can actually be None.
|
Diff from mypy_primer, showing the effect of this PR on open source code: pytest (https://github.com/pytest-dev/pytest)
+ src/_pytest/_code/code.py:140: error: Unsupported operand types for - ("None" and "int") [operator]
+ src/_pytest/_code/code.py:140: note: Left operand is of type "Optional[int]"
+ testing/deprecated_test.py:125: error: Unsupported operand types for > ("int" and "None") [operator]
+ testing/deprecated_test.py:125: note: Left operand is of type "Optional[int]"
+ testing/deprecated_test.py:125: error: Unsupported operand types for < ("int" and "None") [operator]
+ testing/deprecated_test.py:125: note: Right operand is of type "Optional[int]"
rich (https://github.com/willmcgugan/rich)
+ rich/console.py:1823: error: Incompatible return value type (got "Tuple[str, Optional[int], Dict[str, Any]]", expected "Tuple[str, int, Dict[str, Any]]")
|
|
Do you have a test case? The frame object is implemented in C, and has type There's also some code in CPython that assumes it not to be |
|
This getter returns None if that Edit: It also returns |
|
Good catch, and a bit unfortunate that the Python docs and implementation disagree. |
|
I'm still curious if we have a test case. When would int be negative / when would PyCode_Addr2Line fail? This has non negligible primer impact, so would be useful to be able to explain the issue in the not unlikely case that users complain. |
|
That's a couple thumbs ups, but no replies :-) @jd Any luck with a test case? It sucks to tell users "this can be None, but we don't know when or why". There's also a chance you've run into a CPython bug. |
|
Sorry, I don't have a good test case. I've seen this happening randomly while using the profiler project I work on, but it was reported by a user, not something I saw firsthand. If |
|
Here's a test case: I created this by adding a That said, the test case seems contrived and not something that would come up in practice, so I'm not sure if it's very helpful. |
|
Here's a case where |
|
I think we should just use |
Refs discussion in python#6769
Here's a PR doing that: #6935 |
…er None In some cases, f_lineno can be `None` which would trigger an error in the pprof output. This is not even caught by mypy, and I've proposed a fix here: python/typeshed#6769 This patch makes sure we always use 0 if the line number is `None`. It also makes sure a funcname is always passed — in practice it's now the case, but make sure typing reflects that. Fixes DataDog#3046
…er None (#3099) In some cases, f_lineno can be `None` which would trigger an error in the pprof output. This is not even caught by mypy, and I've proposed a fix here: python/typeshed#6769 This patch makes sure we always use 0 if the line number is `None`. It also makes sure a funcname is always passed — in practice it's now the case, but make sure typing reflects that. Fixes #3046
In very rare (error?) cases, f_lineno can actually be None.