You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure I understand what you mean by "connect" generation numbers. We cannot really change set_threshold because of its signature (that is we cannot just remove the parameter from the signature due to backwards compatibility).
To be precise, what we did is:
Ignore generation=1. It just returns an empty list.
We cannot really ignore threashold1 instead of threshold2 because thos arguments are positional-only.
It's better to keep those names for historical reasons.
@picnixz Ok, I see your point.
Any name changes may lead to compatibility problems…
If we try to change the order of arguments(0->1->2 to 0->2->1) it can make things even worse
If we try to rewrite the gc.get_stats function… we could also get some problems…
Thank you for the explanation!
I can propose to add short comments to each argument, for better readability(if you don't want to read all the text about how things work)
But if it is not needed, I think, the problem is solved)
It's not usual to add comments to arguments in this case. The argument names are historically correct so we'll just be stuck with it. We could rename the arguments but for historical reasons it's maybe better to leave them as is (here the terminology is more important IMO).
As such, I will close the issue for now. Thank you for your understanding!
FTR, it is made by intention to be "compatible" with existing code.
Before 3.14 we have default values for thresholds like (2000, 10, 10). This means that after 100 gc runs (young + middle) we run full collection.
For incremental gc we changed meaning of the second threshold value, and this change documented:
The fraction of the old generation that is collected is inversely proportional to threshold1. The larger threshold1 is, the slower objects in the old generation are collected. For the default value of 10, 1% of the old generation is scanned during each collection.
This means that for default values (2000, 10, 0) after 100 runs we do collection for whole heap like before 3.14.
Activity
picnixz commentedon Nov 30, 2025
I'm not sure I understand what you mean by "connect" generation numbers. We cannot really change
set_thresholdbecause of its signature (that is we cannot just remove the parameter from the signature due to backwards compatibility).To be precise, what we did is:
generation=1. It just returns an empty list.threashold1instead ofthreshold2because thos arguments are positional-only.bobzinin commentedon Nov 30, 2025
@picnixz Ok, I see your point.
Any name changes may lead to compatibility problems…
If we try to change the order of arguments(0->1->2 to 0->2->1) it can make things even worse
If we try to rewrite the gc.get_stats function… we could also get some problems…
Thank you for the explanation!
I can propose to add short comments to each argument, for better readability(if you don't want to read all the text about how things work)
But if it is not needed, I think, the problem is solved)
picnixz commentedon Nov 30, 2025
It's not usual to add comments to arguments in this case. The argument names are historically correct so we'll just be stuck with it. We could rename the arguments but for historical reasons it's maybe better to leave them as is (here the terminology is more important IMO).
As such, I will close the issue for now. Thank you for your understanding!
sergey-miryanov commentedon Nov 30, 2025
FTR, it is made by intention to be "compatible" with existing code.
Before 3.14 we have default values for thresholds like (2000, 10, 10). This means that after 100 gc runs (young + middle) we run full collection.
For incremental gc we changed meaning of the second threshold value, and this change documented:
This means that for default values (2000, 10, 0) after 100 runs we do collection for whole heap like before 3.14.