# Int/str conversions broken in latest Python bugfix releases

**URL:** <https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889>\
**Category:** Core Development\
**Created:** [September 8, 2022, 10:40pm UTC](https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889 "2022-09-08T22:40:32Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![njs](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/njs/32/204_2.png) [@njs](https://discuss.python.org/u/njs)\
**Post date:** [September 9, 2022, 12:58am UTC](https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889/8 "2022-09-09T00:58:38Z")

</div>

> [@gpshead](#):
>
> The CPython internals do not currently have a fully fleshed out concept of an execution context within which _interpreter internals settings_ can be carried around.

ContextVars are designed to be usable for this kind of thing – very cheap to access, opaque namespace so no way for accidental collision or leakage, etc. Decimal and float context settings were two of the major motivating use cases, so this would be right up the same alley.

Obviously the work would still need to be done and I respect not wanting to attempt it in the RC stage; just saying a lot of the infrastructure is already there for when/if someone does take it on.

Having a kwarg to `int` at least to use an explicit limit for a single call seems like a very reasonable addition too.

---

_[View the full topic](https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889)._
