gh-119349: Add ctypes.util function to list loaded shared libraries

[WardBrian]

The dllist() function calls platform-specific APIs in order to list the runtime libraries loaded by Python and any imported modules. If these fail for any reason, None is returned.

The name could surely be bikeshedded, at the moment it is taken from the Julia function of the same name

Previous discussions:

• Add a ctypes.util function to list loaded shared libraries #119349
• https://discuss.python.org/t/a-ctypes-function-to-list-all-loaded-shared-libraries/36370

Code based on https://github.com/WardBrian/dllist by myself with a contribution from @eryksun

• Issue: Add a ctypes.util function to list loaded shared libraries #119349

---

📚 Documentation preview 📚: https://cpython-previews--122946.org.readthedocs.build/

[ghost]

The following commit authors need to sign the Contributor License Agreement:

• [email protected]

Click the button to sign:

[ZeroIntensity]

I'm not a fan of returning None and emitting a warning instead of raising an error. That seems like a potential footgun; I could see developers being very confused as to why their code isn't working if they have warnings suppressed, or simply don't see them (e.g. they're buried in logs).

[WardBrian]

I'm not a fan of returning None and emitting a warning instead of raising an error. That seems like a potential footgun; I could see developers being very confused as to why their code isn't working if they have warnings suppressed, or simply don't see them (e.g. they're buried in logs).

Yes, what to do in the error case is certainly interesting. In my original implementation I returned [], but I can imagine a situation where the platform reports that there actually aren't any shared libraries (if you're in some MUSL, very static, environment, perhaps), so None seemed like a good distinction from [] and matched what ctypes.util.find_library() does

We certainly could let the error propagate, but there isn't much you can do as a user with the exceptions. Most use cases I can imagine would catch the error and then return something falsey, either None or [], and code that deals with this will need to handle that anyway.

[ZeroIntensity]

We certainly could let the error propagate, but there isn't much you can do as a user with the exceptions. Most use cases I can imagine would catch the error and then return something falsey, either None or [], and code that deals with this will need to handle that anyway.

I think we should offload that choice to the user.

[kailando]

It's a good way to show issues without flat-on taking down the (maybe server) program. Could you imagine that happening in GitHub's code storage server code? Kai Griswold

…

On Tue, Aug 13, 2024, 3:34 AM Peter Bierma ***@***.***> wrote: I'm not a fan of returning None and emitting a warning instead of raising an error. That seems like a potential footgun; I could see developers being very confused as to why their code isn't working if they have warnings suppressed, or simply don't see them (e.g. they're buried in logs). — Reply to this email directly, view it on GitHub <#122946 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWUL3JYBIXZW4JVUOVEW4S3ZRHAIPAVCNFSM6AAAAABMMPSC6SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBVGY3TGMRWHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ZeroIntensity]

I am seeing that we're special-casing not having support for AIX. Does CPython even officially support AIX?

[WardBrian]

It's not listed in PEP 11, but there are ~150 other mentions of the platform in the codebase, mostly in test code, like the mentions here.

[picnixz]

I'm not a fan of emitting warnings. Either you silently skip the failed names, or you raise. Or you return bytes and you won't have decoding issues for instance. But if you can list the DLLs being loaded, you should always return the complete list, and if you can't, then you should return None (other functions seem to do it as well when they can't get the result for whatever reason).

[WardBrian]

I'm not sure how long it takes to be reviewed and for the bot to update, but I wanted to note that my employer has filled out the CLA at this point

[ZeroIntensity]

Bikeshedding: if we're going to allow returning None in some cases, we should name this something like find_libraries, for consistency with the None return of find_library.

[ghost]

All commit authors signed the Contributor License Agreement.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @encukou for commit 5ab1b02 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F30617%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @encukou for commit 80be2ab 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F30617%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[encukou]

Android has libc.so, but not libffi.so :(

[ZeroIntensity]

Pretty much LGTM, apart from my many nitpicks. Looking forward to seeing this merged!

[mhsmith]

Android has libc.so, but not libffi.so :(

Android links ctypes against libffi statically. We could change this, but if it's only for this test, then it would be easier to just test for libc on Android instead.

[WardBrian]

Android has libc.so, but not libffi.so :(

Android links ctypes against libffi statically

I went ahead and updated the test to check if either libc.so or libffi.so is in the return on unix-alikes. Hopefully this guards against more platform issues, and we can always add a third candidate to this list if we end up with an even weirder platform that has neither...

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @encukou for commit 1c3594e 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F30617%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[ZeroIntensity]

LGTM! Thanks for doing this and for your patience with reviews, @WardBrian