Hmm, why ignore the error? If a user accidentally sets the variable to something that doesn't work, then they might end up very confused as to why Python is ignoring their request.

I'm hoping this change can be included in the 3.13 RC and so I wanted it as simple and robust as possible. In the 'main' branch, I plan to re-work it so it becomes part of theconfig structure and I would add an error raise there.

Maybe it is safe enough to raise an error here too. That would be consistent with the principle that "errors should not pass silently".

I think that making it return an error rather than nothing should still remain fairly simple,return will just becomereturn _PyStatus_ERR("...") and whatnot.

I haven't paid too much attention to the incremental GC problem (#124567), but I'm assuming that this is a possible solution for it? That should help it go into the 3.13 release

No, I don't think this would be enough for us to feel safe about including incremental GC into 3.13. In retrospect, the incremental GC should have been opt-in for 3.13 and would become default in 3.14 if people had good experience with it.

The point of this env var is to increase the chances that people will test their programs with a higher threshold with 3.13 and then when 3.14 release nears, we would have a better idea about how "aggressive" the default GC tuning should be.

Returning an error_PyGC_Init results in this kind of error:

Fatal Python error: _PyGC_Init: Invalid PYTHON_GC_THRESHOLD value.Python runtime state: preinitializedCurrent thread 0x00007fe0505d6740 (most recent call first):  <no Python frame>

I think that makes sense. We do the same for other env vars.

I'm hoping this change can be included in the 3.13 RC and so I wanted it as simple and robust as possible.

Since we have already reached thefeature-freeze stage and this is a new feature, it needs confirmation from@Yhg1s.

That's right. It's Thomas's call and I completely understand if he doesn't want it. There has already been a bit too much excitement with the RCs.