This method collects all methods defined in the class and its parents.
Similar to `getPropertiesInherited` and `getClassAttributesInherited`.
GitOrigin-RevId: 8dcec5a002ffa105083ece6f4418d51e6d8c2879
The logic is similar to that for instance attributes. Top-level class
attributes and methods defined in the class body get the precedence,
followed by class attributes defined with assignments in @classmethods
unless the latter would resolve to the same assignments as in
cls.attr = cls.attr + 1
finally, we scan through all other class methods resolving the name
to the first definition inside one of them.
So far, I intentionally didn't expose such attributes in findClassAttribute()
or getClassAttributes() because users of these methods assume that
this API considers only attributes defined immediately in the class body.
Adding extra definitions from class methods might break these usages.
I had to update the inspection about typing.Final, because it relied
on the fact that resolve() on assignment targets on class objects can
lead only to those top-level class attributes, where type hints are normally
located, but now it can lead to assignments to a qualified attribute inside
a containing class method.
GitOrigin-RevId: 0ca5bdaa4efca127ac187e822a49df6795e1028a
Icons removed from SDK package (no need to have a separate class for it), ultimate icons moved out of community module.
There are only 3 icon packages in community:
* `PythonParserIcons`
* `PythonPsiApiIcons`
* `PythonIcons` (aka `intellij.python.community.impl`)
Latter two have `.json` mapper to replace old icons with new one for New UI which is included into corresponding `.xml` file.
GitOrigin-RevId: 0438ad4485b5a82a89c81ec63ae6e575d5bb52de
Inherit PyTypeAliasStatement from PyQualifiedNameOwner to re-use type aliases stack in PyTypingTypeProvider
Various tests for the changes above
Co-authored-by: Mikhail Golubev <mikhail.golubev@jetbrains.com>
GitOrigin-RevId: 242427c6f84c05ec48c94085f20675b8e30f8625
TypeVarTuples, i.e. type parameters, such as *Ts, and unpacked tuples types, i.e.
concrete types, such as *tuple[int, ...], are two independent entities in the type
system. Keeping them both represented as a single type is confusing and introduces
a lot of bookkeeping for accessing their state and filtering out unpacked tuples in
every place where a type parameter is expected.
For cases where both types are applicable, and we need to distinguish them from regular
"non-unpackable" types, PyVariadicType marker interface was introduced.
Also, make the API names more consistent with the PEPs terminology: "unbound" unpacked
tuple types instead of "homogeneous" unpacked tuple types.
GitOrigin-RevId: be77eae46fd78512eaf74d5a9709faacc762e45f
Even though LanguageLevel enum items are already sorted by the corresponding
version, I decided to introduce a dedicated comparator to make sure that the
logic of isOlderThan/isAtLeast is used for compareTo, not the default order of
enums.
GitOrigin-RevId: f1d4845154c9b71e920e2b634ea6339643bf9467
