python / python/cpython

Replace ctypes.DllGetClassObject and remove DllCanUnloadNow

Open
#127,369 29 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

extension-modules OS-windows topic-ctypes
Dominant language
Python
Stars
77.2k
Forks
35.9k
PR merge metrics
PR metrics pending

Description

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 DllCanUnloadNow exported from _ctypes should be changed to always return S_FALSE. We should change that now, without a deprecation period. (Note that the comtypes hook 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 a DeprecationWarning. In about Python 3.18, it should be changed to do nothing, just, return CLASS_E_CLASSNOTAVAILABLE.
  • comtypes should be changed: on import, it should replace ctypes.DllGetClassObject with 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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the linked pull request gh-127766 and the issue's proposed changes to ctypes.DllGetClassObject and DllCanUnloadNow. Trace the existing ctypes hooks and the comtypes.server.inprocserver integration described here; done means the API and deprecation behavior are agreed, implemented without unintended comtypes breakage, and covered by the relevant tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
operating-systems
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.