Isolate the _decimal extension module

[CharlieZhao95]

This issue is used to track the PRs split from gh-103092. Isolate the _decimal extension module by:

• Establish a global module state and convert static types to heap types
• Move other global static variables to the global module state(possibly multiple PRs)
  • DecimalException
  • basic_context_template
  • tls_context_key
  • cached_context
  • current_context_var
  • default_context_template
  • extended_context_template
  • round_map
  • Rational
  • SignalTuple
  • External C-API functions
• Convert the global module state to true module state
  • signal_map
  • cond_map
  • convert global state to module state

See original issue Isolate Stdlib Extension Modules and PEP-687 for details.

Linked PRs

• gh-106078: Convert _decimal types to heap types #106079
• gh-106078: Move DecimalException to global state #106301
• gh-106078: Move context template to decimal module global state #106346
• gh-106078: Move static objects related to CONTEXTVAR to the decimal module global state #106395
• gh-106078: Move static variables initialized once to decimal module global state #106475
• gh-106078: Move external C-API functions to decimal module global state #106616
• gh-106078: Prepare to isolate decimal module #106880
• gh-106078: Isolate decimal module #107287
• gh-106078: Suppress the warning caused by multi-phase initialization of decimal #107524

[erlend-aasland]

What is your next step, @CharlieZhao95?

[CharlieZhao95]

What is your next step, @CharlieZhao95?

I think next we can move the remaining static global PyObject to global_state:

• DecimalException
• basic_context_template
• current_context_var
• default_context_template
• extended_context_template
• round_map
• Rational
• SignalTuple
• External C-API functions

This shouldn't be too complicated. The only question is whether we should move these external-API functions, which simply hold function pointers used by numeric types, such as nb_multiply, nb_floor_divide and so on. They will not change during the lifecycle of the program.

[erlend-aasland]

Pick the low-hanging fruit first. It is better with multiple small PRs than one big.

[CharlieZhao95]

Pick the low-hanging fruit first. It is better with multiple small PRs than one big.

Okay! let's go step by step. I will put the objects listed above into multiple small PRs.

[CharlieZhao95]

The second stage has been completed. All documented static variables are moved to the global state. Thanks for review! @erlend-aasland @kumaraditya303

Based on the experience of the original PR, we should also move the signal_map into the module state before converting the global state. This array of structures contains potentially global variables(ex).

typedef struct {
    const char *name;   /* condition or signal name */
    const char *fqname; /* fully qualified name */
    uint32_t flag;      /* libmpdec flag */
    PyObject *ex;       /* corresponding exception */
} DecCondMap;

static DecCondMap signal_map[] = {
    ...
}

IMO, the next stage should be:

1. Move signal_map to global state
2. Convert the global module state to true module state

How about opening a draft PR (convert the global module) first? This will allow us to see failed test cases raised by signal_map more clearly. Or do I just start moving signal_map into global state?

[erlend-aasland]

How about opening a draft PR (convert the global module) first? This will allow us to see failed test cases raised by signal_map more clearly. Or do I just start moving signal_map into global state?

FTR, I often open PRs on my own fork to check CI issues, so that I won't pollute the CPython PR list too much.

Also: I'll be away for the rest of summer, so my response time will probably be slower than usual, just so you know :)

[erlend-aasland]

Great work, @CharlieZhao95 and @kumaraditya303!