• Convertcond_map to heap type (not recorded inglobal-to-fix, but it seems like we should handle it)

I'm not sure I follow;cond_map is not atype.

Remove redundant code and improve some dirty code

Can you please spell this out? We cannot guess what you mean by this :)

• Convertcond_map to heap type (not recorded inglobal-to-fix, but it seems like we should handle it)

I'm not sure I follow;cond_map is not atype.

Background

When I executedtest_decimal.py after moving all variables inglobal-to-fix.csv intodecimal_state, it raised an error:

Traceback (most recent call last):  File"F:\CPython\github\cpython\Lib\test\test_decimal.py", line 5900,in<module>    test_main(arith=True, verbose=True)  File"F:\CPython\github\cpython\Lib\test\test_decimal.py", line 5840,in test_main    init(C)  File"F:\CPython\github\cpython\Lib\test\test_decimal.py", line 110,in init    DefaultTestContext = m.Context(                         ^^^^^^^^^^KeyError:'invalid signal dict'

I found that the place where the error occurs isPyDict_GetItemWithError(val, cm->ex) indict_as_flags. This seems to be caused by the staticsignal_map whose members are assigned to types in module state.

So I guesssignal_map should be moved todecimal_state (you can view mylatest commit, maybe it's not the best solution). Likewise,cond_map[i].ex will be assigned tosignal_map[i].ex, so it probably needs to be moved as well.

I'm not sure if these works are necessary, please correct me if I'm wrong :)

Remove redundant code and improve some dirty code

Can you please spell this out? We cannot guess what you mean by this :)

Of course, there is currently some unclean code. For example,signal_map_init or some code with FIXME comments, they work but are ugly. I will list the code that need to be modified after I have finished thinking. :)

Remove redundant code and improve some dirty code

Can you please spell this out? We cannot guess what you mean by this :)

Of course, there is currently some unclean code. For example,signal_map_init or some code with FIXME comments, they work but are ugly. I will list the code that need to be modified after I have finished thinking. :)

Is this code added by this PR, or code that is already there? For the latter, please do not include such changes in this PR. Instead, create an issue (unless there already is one), explain what you intend to do, and create a separate PR. This PR should focus on isolating_decimal, and nothing else.

If this code added by this PR, or code that is already there?

Sorry for not being clear. I mean the code added by this PR. I like to leave "FIXME" in my code to remind myself of potential work :)

I tested the reference counts usingerlend's script and they look well.

$./python measure.pybefore=90491, after=93999before=94000, after=94000before=94000, after=94000before=94000, after=94000before=94000, after=94000

Also, I compared the execution time of thetest_decimal between the current branch and python3.12, and there is no significant change in them. More detailed benchmark results can be viewed in Python Speed ​​Center after the merge.

Of course, there is currently some unclean code. For example,signal_map_init or some code with FIXME comments, they work but are ugly. I will list the code that need to be modified after I have finished thinking. :)

The code that I can think of that may need to be improved is as follows:

1. If we call thempd_setminalloc functionmultiple times, this function is called indecimal_exec, it will raise a warning. I temporarily use a static variable to ensure that it is not called multiple times. This doesn't seem pretty, any suggestions for improvement?
2. Should we movesignal_map intodecimal_state(to fix the failing test cases, please seecomment), is there a better solution?

🤖 New build scheduled with the buildbot fleet by@kumaraditya303 for commit58f0049 🤖

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

I'm sorry, but I don't have the bandwidth to review this in the near future.

IMO, we should break this up into multiple PRs, like we did with_io; it will be easier to bisect if (when) bugs appear. See alsoPEP-687 for suggestions on how to break this up.

IMO, we should break this up into multiple PRs, like we did with_io; it will be easier to bisect if (when) bugs appear. See alsoPEP-687 for suggestions on how to break this up.

Thanks. This PR made a lot of changes at the same time, which might make it difficult to review. But the_deciaml module is simpler than the_io module, and I think 4~5 PRs are enough.

I plan to break the PR into the following parts:

1. Establish a global module state and port some simple static types
2. Move other global static variables to the global module state
3. Convert the global module state to true module state

Potential work: Add Argument Clinic (It might be worth opening a new issue)

And I noticed that@kumaraditya303 has already done some review work, what do you think?

SGTM, ping me when you are done,