GeezerVison

How about exposing CapsuleType directly, for example as sys._CapsuleType, so that we get rid of the _socket dynamic loading hack?

It feels wrong to expose CapsuleType in sys (I don't believe there are any other types defined on the module?). Perhaps the ideal would be a _types extension module that types could import from?

Obviously that would be a much larger change: I can justify backporting this PR as a bugfix, but not a new module!

A

A micro-optimization is not a bugfix, so you shouldn't backport this PR in any case :)

The proposal to add a private symbol in sys was just pragmatic, precisely so that we don't create a new private extension module for a single symbol.

True! (removed labels)

Let's see if anyone else has an opinion, otherwise I'll have a look into the sys approach.

A

I don't think it's the correct place but at the same time the sysmodule says:

Various bits of information used by the interpreter are collected in module 'sys'.

So it could be the correct place, albeit not the most intuitive one. Note that we already do SimpleNamespace = type(sys.implementation). However, be careful that the sys variable is explicitly deleted so you might want to need a re-import in __getattr__ anyway as it's lazy (the reason is that it's to avoid exposing the variable as types._sys).

OTOH, we have a TODO note:

class _GeneratorWrapper:
    # TODO: Implement this in C.

so this might also be an opportunity to have a true _types built-in module.

so this might also be an opportunity to have a true _types built-in module.

Which I implemented a few months ago. I did it for fun to see what kind of speedups it would provide, but didn't think the added complexity was worth upstreaming.

What do you think of this approach? The compexity would come from converting _GeneratorWrapper. The commits I've just pushed simply expose SimpleNamespace and CapsuleType, and nothing further (the full conversion could be explored in a dedicated PR).

A

This approach looks good to me.

From a build perspective I believe it should be configured correctly for static linking, I borrowed the configuration for _typing in large part. A good sign is that '_types' in sys.builtin_module_names is True.

I like this approach, though would want someone else's signoff because I'm not as familiar with the Modules/Setup changes. Provided the module is always statically linked, it ought to be fine.

cc @gpshead for a quick look perhaps.

@AA-Turner Do you mind if I/someone run the buildbots to make sure that the new module builds properly?

🤖 New build scheduled with the buildbot fleet by @AA-Turner for commit b7f5df1 🤖

Results will be shown at:

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

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

The ARM64 macOS failure is in test_idle, and the two ARM64 Windows failures also look unrelated (I think we have known problems on Windows/ARM at present?).

A

Especially for CapsuleType it's not possible to have a pure-Python fallback. If other implementations don't want to alter types.py then they could e.g. provide the various names in a _types.py which would be picked up, but they will already have strategies for dealing with the general problem.

A