That’s a good point and argues in favor of just adding the keyword only argument to choose the dict return type.
Deprecation period is not possible, because the result should be a dict or a tuple, not both.
It is possible. Our standard API PEP 387 – Backwards Compatibility Policy | peps.python.org deprecation cycle is already reasonable for this:
- adding return_python_dict=False kwarg can happen in 3.13, with documentation saying the non-dict behavior will be deprecated and require the flag in the future.
- in either 3.13 or 3.14 have calls where that argument is not supplied emit a DeprecationWarning about the upcoming default behavior change.
- two releases later (.15 or .16) change the default to True, removing the warning.
We never need to remove the argument. And never need to remove support for the old =False behavior. While those could be done in followup deprecation cycles, it isn’t required, and would just cause more churn in doing so as you’ve noted. So I’d just track them as a followup low priority issue and be surprised if anyone is motivated to bother with those arg removal old behavior removal steps. (the tkinter code does not see much change)