私は、パイロン用の非常に単純なクラッド ジェネレーターに取り組んできました。調べるものを思いついた
SomeClass._sa_class_manager.mapper.c
これを調べても (またはアンダースコアで始まるメソッドを呼び出しても) 大丈夫ですか? クラス/オブジェクトの内部構造に大きく依存しているため、眉をひそめていますが、これは常に合法であると想定していました。でもまあ、Python には Java の意味でのインターフェースが実際にはないので、多分それでいいのです。
私は、パイロン用の非常に単純なクラッド ジェネレーターに取り組んできました。調べるものを思いついた
SomeClass._sa_class_manager.mapper.c
これを調べても (またはアンダースコアで始まるメソッドを呼び出しても) 大丈夫ですか? クラス/オブジェクトの内部構造に大きく依存しているため、眉をひそめていますが、これは常に合法であると想定していました。でもまあ、Python には Java の意味でのインターフェースが実際にはないので、多分それでいいのです。
「プライベート」スコープがないのは (Python では) 意図的です。アンダースコアで始まるものは理想的には使用すべきではないという慣例があるため、次のバージョンでその動作や定義が変更されても文句を言う必要はありません。
一般に、これは通常、メソッドが文書化されたインターフェースの一部ではなく、事実上内部のものであり、依存すべきではないことを示します。ライブラリの将来のバージョンでは、そのようなメソッドの名前を自由に変更したり、削除したりできるため、将来の互換性を気にする場合は、書き直す必要はありません。
すでに述べた理由から、一般的には良い考えではありません。ただし、Pythonは、他に何かを行う方法がない場合に備えて、意図的にこの動作を許可しています。
たとえば、作成者が特定のオブジェクトの内部状態に直接アクセスする必要があるとは思わなかったが、実際にはそうしている、クローズドソースのコンパイル済みPythonライブラリがある場合でも、必要な情報を取得できます。異なるバージョンに追いつくことについて前に述べたのと同じ問題がありますが(幸運にもそれが維持されている場合)、少なくとも実際にはやりたいことを行うことができます。
それが機能する場合、なぜですか?ただし、_sa_class_manager が再構築されたり、この特定のバージョンの SQLAlchemy にバインドしたり、変更を追跡するためにさらに作業を作成したりすると、問題が発生する可能性があります。SQLAlchemy は目まぐるしく変化するターゲットであるため、1 年以内にそこに到達する可能性があります。
望ましい方法は、目的の API を SQLAlchemy 自体に統合することです。