GH-118761: Expose more core interpreter types in _types

[AA-Turner]

This was discussed in #131969 (cc @ZeroIntensity), but deferred to get the smaller change in. This PR adds all of the core interpreter types currently exposed in the types module to _typesmodule.c. We then change the definition of types.py to prefer these, but if the _types module is not available, to use the pure-Python fallbacks.

Strictly, this isn't needed, as _types is a built-in module. I think it might be helpful to keep the pure Python definitions for other implementations (PyPy, etc), and perhaps as a quick reminder of what each type looks like. Open to thoughts on this, as it would clearly be simpler to replace everything with from _types import *.

I've initially categorised this under #118761, as this does provide a ~15% speed-up for me (1627µs to 1403µs).

A

• Issue: Improve import time of various stdlib modules #118761

[ZeroIntensity]

It might be worth adding a _pytypes module to hold the pure-Python fallbacks.

[AA-Turner]

It might be worth adding a _pytypes module to hold the pure-Python fallbacks.

As in the following?

try:
    from _types import *
except ImportError:
    from _pytypes import *

Could you elaborate on the benefits?

[picnixz]

Could you elaborate on the benefits?

One benefit is that it reduces by one the indentation level and it's easier to read/modify I think. Also, we do it for _pydecimal so why not doing it for _pytypes?

[ZeroIntensity]

Could you elaborate on the benefits?

Yeah, what Bénédikt said. It seems cleaner to encapsulate each implementation.

[AA-Turner]

Also, we do it for _pydecimal so why not doing it for _pytypes?

_pydecimal, _pyio, etc are Python implementations of the C accelarator modules (see PEP-0399), whereas types still contains quite a lot only implemented in Python. See e.g. collections and functools which use extension modules, but don't have a _py<mod> helper module.

A

[ZeroIntensity]

I don't have much of a preference, it's just prettier. Are we planning to implement the other functions in C?

[AA-Turner]

Are we planning to implement the other functions in C?

I'm not personally, though Yury left a TODO comment by _GeneratorWrapper about implementing it in C. I'd probably prefer to keep the simpler functions in Python, but there might be benefits I haven't considered to converting to C.

A

[ZeroIntensity]

LGTM. Let's do a _pytypes module in a follow-up if we decide to implement the rest of the functions in C.

[picnixz]

Just some cosmetic suggesetions. Concerning the spaces before the comments, I don't think we now need to have some column-aligned comments (it's not even clear that they are aligned in the first place).