Int/str conversions broken in latest Python bugfix releases

As much as I agree with the sentiment, this was a practicality beats purity decision.

I totally get why you and some others dislike this change. We’re really sorry for those who this change causes pain. We tried to pick something that limited the global amount of pain caused. Python’s user base and usage scenarios are quite diverse. We saw no way to satisfy everyone.

Your example showing 10k int( calls in a project also happens to demonstrate why. All of those could need auditing to determine if they might ever handle huge data. Same with str( %s "{}" repr %r %d and so on. Such auditing would need to happen and be redone continually as code evolves, new code is added, new call paths use code transitively throughout the application, etc. So we chose the “secure by default” approach as that flips the story such that only the less common code that actually wants to deal with huge integers in decimal needs to do something simpler in response to this: raise or disable the limit and live life as they always have.

Could this have been done better? Undoubtedly. Was there anyone who was going to do it? No. So we made the decision.

When doing something that is needed as a back-ported security fix our options are restricted to non-invasive changes. Ex: We can’t add a parameter to int() or new intended for heavy use library functions in patch releases. Those are all good ideas for 3.12+ as features where we have a chance to define a happier integer story for everyone using Python. It wouldn’t surprise me if third party PyPI libraries spring up offering things along these lines to existing versions as well.

Similarly if we don’t address something in a particular supported Python release, other distributors of Python who have customers demanding security mitigation may cause them to provide one whether we like what they’ve done or not. If we don’t offer a recommended solution ourselves, they could wind up doing their own thing to their runtime, fragmenting the community compatibility matrix further.


(Steering Council hat:)

We don’t take this kind of change lightly.

We weren’t happy with any of the available options.

But those also included not being happy with continuing to do nothing and sitting on it for longer, or continuing to do nothing and letting it become public directly or via any of the disappointed at our lack of action reporters.

6 Likes