What’s Fixed and Improved in PyCharm 2026.2

JetBrains released PyCharm 2026.2 with 263 fixes and improvements, focusing on Python code insight, type inference, and SQLAlchemy 2.0 support. The update resolves long-standing false positives in SQLAlchemy, improves control-flow narrowing, and fixes type inference for iterable unpacking and augmented assignments.

Releases /pycharm/category/releases/ What’s Fixed and Improved in PyCharm 2026.2 Across the PyCharm 2026.2 release line, we shipped 263 fixes and improvements https://youtrack.jetbrains.com/issues?q=%23py%20type:%20bug%20%23resolved%20Planned%20for:%202026.2,%20%7B2026.2%20 %7D,%202026.2.1%20visible%20to:%20%7BAll%20Users%7D . Many improve Python code insight directly, with more precise type inference, fewer false positives, smarter completion and imports, and more reliable refactoring. Here are some of the smaller changes you’re likely to notice in everyday Python development. SQLAlchemy 2.0 support SQLAlchemy has been a long-standing source of false positives – enough that several duplicate tickets have accumulated over the years. This release resolves a batch of them for the 2.0 style. String forward-references inside Mapped ... resolve correctly: posts: Mapped list "Post" = relationship back populates="author" "Post" now resolves to the model class PyCharm also correctly infers the mapped type returned by Session.get , instead of treating the result as the model class itself: report = session.get Report, report id reveal type report was: type Report | None now: Report | None Modern hybrid property setters written as @name.inplace.setter are recognized, so assigning to the property no longer produces a warning. Model class attributes defined via mixins are picked up again, too, clearing the old unexpected argument reports on model constructors. PY-78816 https://youtrack.jetbrains.com/issue/PY-78816 , PY-65142 https://youtrack.jetbrains.com/issue/PY-65142 , PY-59732 https://youtrack.jetbrains.com/issue/PY-59732 , PY-51906 https://youtrack.jetbrains.com/issue/PY-51906 , PY-28762 https://youtrack.jetbrains.com/issue/PY-28762 Code insight and type inference Control-flow narrowing and “unreachable code” Several false This code is unreachable reports and instances of lost narrowing across loops have been fixed. The common issue: flow analysis either gave up or over-eagerly narrowed to Never in branches it should have kept alive. isinstance on a numeric union no longer kills the else branch: php def foo y: int | float - None: if isinstance y, float : pass else: print y was flagged unreachable, y inferred as Never Narrowing also survives a while loop, so re-narrowing an optional attribute inside the loop body no longer reports a bogus has no attribute error. PY-83206 https://youtrack.jetbrains.com/issue/PY-83206 , PY-83354 https://youtrack.jetbrains.com/issue/PY-83354 , PY-88265 https://youtrack.jetbrains.com/issue/PY-88265 Strings inside type annotations A string used as metadata inside Annotated ... – a Pydantic discriminator field name, for instance – is no longer parsed as a forward reference and flagged as unresolved. Iterable unpacking and star expressions PyCharm’s analysis of tuple and star unpacking could lose type information and fall back to Any . Unpacking a starred value into a tuple lost its element types, -expansion collapsed to Any , and several genuine errors went unreported. Starred expressions preserve their element types: php def a - tuple int, int : return 2, 3 def b - tuple int, int, int : return 1, a no more bogus "Expected tuple int, int, int " PY-12592 https://youtrack.jetbrains.com/issue/PY-12592 , PY-27205 https://youtrack.jetbrains.com/issue/PY-27205 , PY-43585 https://youtrack.jetbrains.com/issue/PY-43585 , PY-90219 https://youtrack.jetbrains.com/issue/PY-90219 Augmented assignment A cluster of false positives came from augmented assignments being misanalyzed. A simple /= on an int produced the wrong type: foo = 5 foo /= 2 reveal type foo was: int now: float | int PY-80622 https://youtrack.jetbrains.com/issue/PY-80622 Self and constructor return types Self binds correctly through classmethod parameters typed as type Self : php class A: @classmethod def bar cls, y: type Self - Self: ... x = A.bar A was a spurious "Expected type A , got type A " reveal type x was: Any now: A Construction also respects new , init , and metaclass call . When new returns something other than an instance, that’s the constructed type – even when an init is present. The same fix covers explicitly parameterized calls like MyClass int and new assigned as a class attribute. PY-89296 https://youtrack.jetbrains.com/issue/PY-89296 , PY-77611 https://youtrack.jetbrains.com/issue/PY-77611 , PY-88644 https://youtrack.jetbrains.com/issue/PY-88644 , PY-89571 https://youtrack.jetbrains.com/issue/PY-89571 Enum members: Literal types for .value and .name Reading an enum member’s .value or .name yields a precise Literal instead of a widened str or int , so assignments to Literal ... target type-check. This matches mypy ’s inference: python from enum import Enum from typing import Literal class E Enum : a = "a" b: Literal "a" = E.a.value was: Expected 'Literal "a" ', got 'str' n: Literal "a" = E.a.name .name is a Literal too Parameter types inferred from decorators When a decorator constrains the callable it accepts, the decorated function’s parameters are inferred from that constraint instead of falling back to Any : python from typing import Callable def d fn: Callable int , str : ... @d def f a : reveal type a was: Any now: int PY-79204 https://youtrack.jetbrains.com/issue/PY-79204 Also fixed - Keyword arguments in a class header are validated against the base class’s init subclass signature, and offered in completion PY-79173 https://youtrack.jetbrains.com/issue/PY-79173 . - An ellipsis in a Callable used as a PEP 695 type-parameter bound no longer reports a bogus Invalid type expression PY-83570 https://youtrack.jetbrains.com/issue/PY-83570 . - Type-checker findings are split into granular suppression codes rather than a single PyTypeChecker id, and noinspection directives accept a simplified name form. PyTypeChecker still works as a blanket ignore PY-90265 https://youtrack.jetbrains.com/issue/PY-90265 . Completion and auto-import Smarter auto-import Auto-import is now noticeably less noisy. Previously, if a module was already imported, PyCharm would offer to add a second, redundant import instead of qualifying through the one you already had. The quick-fix – and the completion popup – prefer to reuse the existing import. Given pkg/src.py containing MyClass , and a file that already imports the module, Alt + Enter produces this: python from pkg import src no longer flagged as unused src.MyClass instead of adding from pkg.src import MyClass . The same reuse logic applies to plain import pkg.src , and to the auto-import completion on a second Ctrl + Space . Nested classes can be auto-imported too, which is something PyCharm didn’t previously support: mod.py class Outer: class Inner: pass main.py – Alt+Enter on Inner now offers "Import Outer from mod" from mod import Outer value = Outer.Inner PY-87970 https://youtrack.jetbrains.com/issue/PY-87970 , PY-87971 https://youtrack.jetbrains.com/issue/PY-87971 , PY-87972 https://youtrack.jetbrains.com/issue/PY-87972 , PY-88009 https://youtrack.jetbrains.com/issue/PY-88009 , PY-88016 https://youtrack.jetbrains.com/issue/PY-88016 Completion for unittest.mock.patch targets Patching by string target previously offered no code assistance, so dotted paths had to be entered manually. The string argument to mock.patch ... gets code completion for modules, classes, and their attributes, and it no longer suggests the invalid as keyword mid-path: python from unittest import mock sample.py defines: class Foo: my attr = 42 with mock.patch "sample.Foo.my attr", 14 : ... completion now offers sample , Foo , and my attr PY-89189 https://youtrack.jetbrains.com/issue/PY-89189 , PY-89191 https://youtrack.jetbrains.com/issue/PY-89191 , PY-89192 https://youtrack.jetbrains.com/issue/PY-89192 Typed signatures when overriding built-in methods Completing an override of a dunder or built-in method fills in the full annotated signature – and auto-imports the types it needs – instead of bare parameters: python from types import TracebackType class A: def exit self, exc type: type BaseException | None, exc val: BaseException | None, exc tb: TracebackType | None : ... was: def exit self, exc type, exc val, exc tb : PY-79218 https://youtrack.jetbrains.com/issue/PY-79218 Editor and inspections Type inlay hints Inferred type arguments are shown inline at the call site, so you can see what a generic resolved to without hovering over it: python class A T : def init self, t: T : ... A int 1 int shown as an inlay hint Type names rendered inside inlay hints – return types and solved arguments alike – are also clickable, so you can jump straight to a type’s definition from the hint. f-string format-spec validation PyCharm already validated the str.format mini-language. Those checks apply to f-strings too, and PyCharm flags formatting a type that doesn’t implement format : data = 1 f"{data:.2f}" ok f"{data:.2q}" now flagged: unsupported format spec class A: ... f"{A :d}" now flagged: A doesn't support the 'd' format Refactoring The Rename refactoring also updates references to a module when the module itself is renamed. Previously, the renaming left importing sites pointing at the old name: python rename provider/provider module.py → some module.py from ..provider import provider module this reference is updated too PY-53274 https://youtrack.jetbrains.com/issue/PY-53274 The Refactor | Field action is now Attribute , and the documentation says “instance attributes” to match Python terminology PY-85828 https://youtrack.jetbrains.com/issue/PY-85828 . Conclusion Taken together, these changes make PyCharm’s understanding of Python more precise and predictable: fewer false positives, better type inference, smarter completion, and less time spent working around cases where the IDE gets valid code wrong. Many of these improvements started with real-world examples reported by users. If PyCharm still misunderstands a typing pattern, framework API, or other valid Python code in your project, let us know in YouTrack – a small reproducer can help us turn that friction into the next fix. Try PyCharm 2026.2 https://www.jetbrains.com/pycharm/ and let us know which improvements make the biggest difference for your workflow. Thank you for using PyCharm Subscribe to PyCharm Blog updates