そのため、 PythonをSchemeプログラムに埋め込むことができるように、libpythonにバインドするSchemeを作成することにしました。私はすでにPythonのCAPIを呼び出すことができますが、メモリ管理についてはあまり考えていません。
mzschemeのFFIが機能する方法は、関数を呼び出すことができ、その関数がへのポインターを返す場合PyObject、参照カウントを自動的にインクリメントさせることができます。次に、Schemeオブジェクトがガベージコレクションされたときに参照カウントをデクリメントするファイナライザーを登録できます。参照カウントのドキュメントを確認しましたが、一見したところ問題はありません（ただし、場合によっては最適ではない場合もあります）。私が見逃している落とし穴はありますか？
また、サイクリックガベージコレクタのドキュメントの先頭または末尾を作成するのに問題があります。ここで心に留めておくべきことは何ですか？特に、Pythonに何かへの参照があることを認識させて、まだ使用している間はそれを収集しないようにするにはどうすればよいですか？
http://docs.python.org/extending/extending.html#reference-countsへのリンクは適切な場所です。ドキュメントの拡張と埋め込みおよびPython/C APIのセクションは、CAPIの使用方法を説明するセクションです。
参照カウントは、CAPIを使用する際の厄介な部分の1つです。主な落とし穴は、すべてをまっすぐに保つことです。呼び出すAPI関数に応じて、取得したオブジェクトへの参照を所有している場合と所有していない場合があります。あなたがそれを所有しているか（したがって、それをDECREFすることを忘れたり、それを盗むものに与えることを忘れることはできません）、それを借りているか（そしてそれを保持し、おそらくあなたの機能中にそれを使用するためにそれをINCREFする必要があります）を理解するように注意してください。これに関連する最も一般的なバグは、1）特定の関数によって返された参照を所有しているかどうかを誤って記憶していること、および2）自分よりも長い時間参照を借りても安全であると信じていることです。
サイクリックガベージコレクターのために特別なことをする必要はありません。参照カウントの欠陥を修正するためだけにあり、直接アクセスする必要はありません。
参照カウントとCAPIで私が知っている最大の落とし穴が__del__問題です。何かへの参照を借用している場合、その参照を使用している間はGILを放棄しないため、INCREFを使用せずに逃げることができると思います。ただし、オブジェクトを削除することになった場合（たとえば、リストからオブジェクトを削除するなど）、__del__呼び出しをトリガーする可能性があります。これにより、借用している参照が足元から削除される可能性があります。非常にトリッキーです。
借用したすべての参照を取得したらすぐにINCREF（そしてもちろんDECREF）しても、問題はありません。