possible memory leaks and issues during finalizer about freetype-py HOT 1 OPEN

Calling it a memory leak is not entirely correct. It is rather than freetype-py did not automatically tidy things up in the right order. So if you have python destructors automatically calling the destructors in c for you, then you may have segfaults when python does not destroy them in the right order; the "fix" at some point in the past was to NOT automatically call c desctructors from python instructors, and just not tidy up at all, and rely on the OS to tidy up on exit of the python script. If you are familiar with freetype enough, you can manually calls the c destructors from freetype-py in the right order within, for long-running freetype-py scripts.

I think it may be a little too much bending over for users' convenience to have automatic tidy up that "works". The c-side is basically library have faces, faces have glyphs, glyphs have bitmaps and outlines, etc. And each of those have "up" references and know what they belong. C users always creates in one direction of order and destroy it from the opposite order.

If you want convenient automatic tidy up to work I.e. you use a whole bunch of faces, find a whole bunch of glyphs, draw a whole bunch of outlines and bitmaps, and then just move on, and hope that freetype-py to tidy them up for you, there will be a whole lot of code on the python side tracking what owns what and what references what. Like if you destroy a face, do you destroy all its associated glyphs and bitmaps now, or do some lazy thing and marked it as deleted but not, and wait until the last glyph/bitmap's with this face is destroyed before actually destroying the face?

from freetype-py.