# Use function annotations to improve bytecode specialization? **URL:** \ **Category:** Ideas\ **Created:** [August 5, 2026, 4:31pm UTC](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422 "2026-08-05T16:31:23Z")\ **Posts on this page:** 8\ **Page:** 2
**Author:** ![UnknownUser03393](https://avatars.discourse-cdn.com/v4/letter/u/f9ae1b/32.png) [@UnknownUser03393](https://discuss.python.org/u/UnknownUser03393)\ **Post date:** [August 28, 2026, 11:57am UTC](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422/21 "2026-08-28T11:57:18Z")
thx for the detailed example – it’s a great proof for showing the Adaptive Intrepter’s fast performance when handling **basic types**. But in practice, most Python code uses complex types:\* `Optional[T]`_,_ `list[T]`_,_ `dict[K, V]`. The adaptive interpreter can’t specialize on these because it only sees the runtime type (e.g., `list`), not the type arguments (`list[str]` vs `list[int]`). That’s the gap I’m trying to fill with type hints. ---
**Author:** ![duncathan](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/duncathan/32/25521_2.png) [@duncathan](https://discuss.python.org/u/duncathan)\ **Post date:** [August 28, 2026, 1:07pm UTC](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422/22 "2026-08-28T13:07:12Z")
My point isn’t that people _should_ write this code - it’s that people _have_ written code like this. A change that suddenly breaks working code is a serious thing. How do you justify breaking backwards compatibility like that? Not to say that it can’t be justified, but it’s an important hill to climb for any idea like this. ---
**Author:** ![UnknownUser03393](https://avatars.discourse-cdn.com/v4/letter/u/f9ae1b/32.png) [@UnknownUser03393](https://discuss.python.org/u/UnknownUser03393)\ **Post date:** [August 28, 2026, 4:44pm UTC](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422/23 "2026-08-28T16:44:57Z")
I understand the backward compatibility argument, but I’d push back: if someone writes name: str and passes an int, the code is already wrong — it’s just not being caught. The type checker would flag it, but not everyone runs a type checker. Making the runtime optionally enforce the annotation (via a flag or decorator) wouldn’t break default behavior, but it would give users who want correctness a way to get it. ---
**Author:** ![Stefan2](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stefan2/32/18492_2.png) [@Stefan2](https://discuss.python.org/u/Stefan2)\ **Post date:** [August 30, 2026, 4:38pm UTC](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422/24 "2026-08-30T16:38:25Z")
> [@duncathan](#): > > breaks working code Are you still talking about [your earlier example](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422/5)? Wouldn’t the existing “fallback” [mentioned by Jesper](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422/9) keep it working? ---
**Author:** ![UnknownUser03393](https://avatars.discourse-cdn.com/v4/letter/u/f9ae1b/32.png) [@UnknownUser03393](https://discuss.python.org/u/UnknownUser03393)\ **Post date:** [August 31, 2026, 8:25am UTC](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422/25 "2026-08-31T08:25:07Z")
I’m wandering about that is Dispatch Inline Caches (IC) good enough. ---
**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\ **Post date:** [September 7, 2026, 8:39pm UTC](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422/26 "2026-09-07T20:39:34Z")
There’s issues with the type system that conflict with wanting to do this even if it weren’t more complex to pass in hints for the smallest of possible gains, like that the type system treats `float` in annotations as if you had written `float | int`, or that the type system currently makes incorrect assumptions about ` __hash__ ` despite how often this topic seems to come up, the combination of the type system having holes and the specializing interpreter doing it’s work relatively quickly from accurate information at runtime keeps this from being something I’d even consider pursuing in more detail. ---
**Author:** ![AIdjis](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/aidjis/32/31875_2.png) [@AIdjis](https://discuss.python.org/u/AIdjis)\ **Post date:** [September 8, 2026, 2:34pm UTC](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422/27 "2026-09-08T14:34:45Z")
In CPython, this approach would not work well because Python is a dynamically typed language. If you assume a value always has the same type, you would need to perform runtime checks continuously to verify that assumption. For hot code paths, this is acceptable. CPython’s adaptive specializing interpreter can observe execution, identify stable type patterns, and replace generic bytecode with specialized bytecode. The cost of these checks is small compared to the performance gains because the code runs frequently. However, for cold code paths (functions or sections of code that are rarely executed) the overhead becomes much harder to justify. You would still pay the cost of the runtime checks, but there may not be enough executions to recover that cost through specialization. In some cases, the code could even become slower than the normal generic implementation. Julia addresses this differently through multiple dispatch and JIT compilation. When a function is called, Julia specializes the function for the concrete argument types and compiles optimized machine code. After the first compilation, later calls with the same argument types can directly execute the previously generated optimized machine code. Bringing a similar model to CPython would introduce significant complexity and would fundamentally change its design philosophy. ---
**Author:** ![Spaceman](https://avatars.discourse-cdn.com/v4/letter/s/a5b964/32.png) [@Spaceman](https://discuss.python.org/u/Spaceman)\ **Post date:** [September 8, 2026, 3:15pm UTC](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422/28 "2026-09-08T15:15:09Z")
There have been different tries with different languages to achieve this but I don’t think it will ever work in Python for the arguments mentioned above. However there is currently work done on Spy(Lang) which seems to conceptually hit the sweet spot. But it’s in its early stages so time will tell if it’ll mature enough or if it’ll stay in the niche like e.g. nim. [Previous page](https://discuss.python.org/t/use-function-annotations-to-improve-bytecode-specialization/108422.md?page=1)