Replace ctypes.DllGetClassObject and remove DllCanUnloadNow
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 35.9k
- PR マージ指標
- PR 指標を取得中
説明
As far as I can tell, these functions are hooks: third-party code is meant to replace them.
Their implementation in ctypes (i.e. their default behaviour) is to import and call the same-named functions from a third-party library, comtypes.server.inprocserver. This is not good. comtypes should instead register their hook on import.
Here's a possible plan to make the API boundary better without breaking users.
DllCanUnloadNow
While the Python interpreter is running, it is not safe to unload the shared library that contains _ctypes. Therefore:
- The C function
DllCanUnloadNowexported from _ctypes should be changed to always returnS_FALSE. We should change that now, without a deprecation period. (Note that thecomtypeshook already does this.) - We should stop importing and calling
comtypes.server.inprocserver. I'm not sure about the necessary deprecation period, but I think that it should be a non-breaking change and can also be done immediately. Or is someone relying on it for side effects? O_o - Setting and getting the hook should be deprecated. In about Python 3.18 we should stop calling it, and remove it.
DllGetClassObject
This one, on the other hand, sounds like a useful hook. It also looks like an inprocess COM server need a special build so it's not useful to allow multiple hooks -- replacing a global one is enough. Is that so?
If yes:
ctypes.DllGetClassObject(the default implementation) should raise aDeprecationWarning. In about Python 3.18, it should be changed to do nothing, just, returnCLASS_E_CLASSNOTAVAILABLE.comtypesshould be changed: on import, it should replacectypes.DllGetClassObjectwith its own hook.
This should ensure that old versions of comtypes still work as before (until after the deprecation period).
Does that sound reasonable?
cc @junkmd
Linked PRs
- gh-127766
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、リンクされているプルリクエスト gh-127766 と、ctypes.DllGetClassObject および DllCanUnloadNow に対して issue で提案されている変更を確認してください。既存の ctypes フックと、ここで説明されている comtypes.server.inprocserver との統合を追跡してください。API と非推奨化の動作について合意され、意図しない comtypes の破損なしに実装され、関連するテストでカバーされれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- operating-systems
- issue の種類
- リファクタリング
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 20/100