My reading of the mypy error is that it simply wants the stub to match the final status of the implementation by adding @final to decorate the class in the pyi. That makes sense to me, though didn't actually try it to check

build failures on windows do appear to be related here.

Ah, interesting that designated initializers are so new in C++ vs C.

Remains true that the errors on Windows appear to be related.

I also put in the deprecated function removals here.

Changing the classes to final needs an API change note as they are technically public.

Do we have any sense of the preformance trade off of doing a single pass but maybe multiple memory allocations vs doing two passes but only one memory allocation?

Do we have any sense of the preformance trade off of doing a single pass but maybe multiple memory allocations vs doing two passes but only one memory allocation?

Running tests with pytest -n4 on my machine, mostly idle, averaging 3 of 5 (dropping best/worst times) gives 236.4 ± 0.3s for the commit before, and 234.4 ± 0.5s after. Now this isn't a true microbenchmark, but at least times aren't horribly worse.

A possibly reasonable microbenchmark:

import string
import timeit

from matplotlib.text import TextToPath
from matplotlib.font_manager import FontProperties, findfont, get_font

ttp = TextToPath()
fp = FontProperties()
font = get_font(findfont(fp))

timer = timeit.Timer("ttp.get_glyphs_with_font(font, string.ascii_uppercase)",
                     globals={'ttp': ttp, 'font': font, 'string': string})

timer.autorange(print)

This ends at 500 iterations, with average before of 0.236 ± 0.014s, and average after of 0.231 ± 0.004s.

Snuck in one more thing; noticed that the C++ side's FT2Image.m_dirty is unused, so removed it.

And ft2font.Glyph was removed from the API change note because the class part is not public; it isn't exposed in the module and can only be used when returned by some other method.