gh-98417: Stop modifying PyConfig in sys.set_int_max_str_digits()

[gpshead]

PyConfig is an input to interpreter initialization; the copy stored on PyInterpreterState records how the interpreter was initialized. The runtime int<->str digit limit already lives in
PyInterpreterState.long_state.max_str_digits and that is what all readers use, so drop the write-back into
interp->config.int_max_str_digits from _PySys_SetIntMaxStrDigits().

As a consequence, interpreters created after a runtime limit change now start from the initially-configured limit instead of inheriting the current runtime value.

---

it's basically a one line change... the question is, is this what we want? we'll resolve that on the issue.

• Issue: PyInterpreterState.config.int_max_str_digits Should Not Be Modified #98417

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[zooba]

I assume it won't change much on its way out of draft, but provided the change is just removing that line then I'm not going to have any concerns

[gpshead]

it doesn't sound like we're settled on this as our behaviors around modifying PyConfig are not consistently read only any more per the issue. closing. we can reopen if this makes sense in the future.

[zooba]

our behaviors around modifying PyConfig are not consistently read only any more per the issue

Victor only showed that the C API is able to mutate it, which is always obviously possible (the PyConfig lives outside of the runtime, so the owner is the host app, and it can do whatever it likes).

A code snippet using the _testcapi module is hardly proof of inconsistency.