This was discovered through a pytype bug. For the following code:

s = []
s.clear()
s.clear()
x: int = "some str"

We expect pytype to raise an annotation-type-mismatch error on the last line. However, the two method calls (s.clear()) cause pycnite to generate the wrong line numbers for the opcodes of this snippet. This makes pytype think that the STORE_NAME x opcode is on line 3, entirely missing the : int type hint and allowing the annotation to go through.

(I have not investigated if other operations besides 2 method calls in a row trigger this behavior.)

I found that LineTableReader311 generates 30 line table entries, while dis generates only 28 opcodes.

In the following code:

import collections
from typing import Any, Mapping
def f(x: str | None):
  y = x
  z = collections.defaultdict(
      lambda: ([], []))  # type: Mapping[int, Any]
  for k, v in z.items():
    key = (y, k)
    v1, v2 = v
    yield (k, v1, v2)

The STORE_FAST y op should be at line 4, but pycnite puts it at line 5.

A pytype PR to use pycnite (google/pytype#1499) fails pytype's tests in Python 3.8 due to the use of the dataclass kw_only option, which is new in 3.10.

I'm thinking I'll fix that, then add a GitHub Actions workflow to run pycnite's tests in 3.8-3.11 and fix any additional 3.8/3.9 incompatibilities that flushes out.

We (FreeBSD ports) mainly use sdist to build python modules.
Previous version (2023.10.11) of pycnite provided sdist (pycnite-2023.10.11.tar.gz) on PyPI.
Please also publish sdist of pycnite 2024.5.27 to PyPI.
Thanks.