# Permitting more precise inferred types from ambiguous overloads **URL:** \ **Category:** Typing\ **Created:** [August 27, 2026, 8:00pm UTC](https://discuss.python.org/t/permitting-more-precise-inferred-types-from-ambiguous-overloads/108776 "2026-08-27T20:00:27Z")\ **Posts on this page:** 1\ **Showing post:** 15
**Author:** ![rchen152](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/rchen152/32/16955_2.png) [@rchen152](https://discuss.python.org/u/rchen152)\ **Post date:** [August 29, 2026, 5:29pm UTC](https://discuss.python.org/t/permitting-more-precise-inferred-types-from-ambiguous-overloads/108776/15 "2026-08-29T17:29:32Z")
Fair, if I’m being more careful with my wording, _following_ this requirement would force pyrefly to produce less precise types. To be clear, if this change lands, I intend to update pyrefly to respect it. For some background, pyrefly followed the overload evaluation section of the spec exactly until this April, when I changed its default behavior because it disagreed with the existing ecosystem in too many places. I also put up a proposed spec change at the time, because the intent was never to deviate from the spec long-term; IMO that’s bad for the type system in all sorts of ways. I also really don’t want to churn pyrefly’s behavior repeatedly, so I’d like to make sure that we’re really okay with the cost of type checkers following the spec here. If we’re all on the same page, I’m not going to try to block this or anything; this would actually make things easier on me from a maintenance perspective because I could just delete pyrefly’s entire `--spec-compliant-overloads` flag and replace it with a three-line loop 🙂 [Here](https://github.com/scipy/scipy-stubs/blob/b7103b7e15d3e59e9c6e60cf9a79a667bbc43b37/tests/stats/test_ttest.pyi#L109) is an actual example from scipy-stubs, although I’m not sure how illuminating it is. --- _[View the full topic](https://discuss.python.org/t/permitting-more-precise-inferred-types-from-ambiguous-overloads/108776)._