This method collects all methods defined in the class and its parents.
Similar to `getPropertiesInherited` and `getClassAttributesInherited`.
GitOrigin-RevId: 8dcec5a002ffa105083ece6f4418d51e6d8c2879
`PythonSdkUtil` duplicates VER logic. One Jython-specific thing was also removed as we do not need Jython anymore
GitOrigin-RevId: 658fc42b485ac074a6d89fce3c7408e51cdc8f95
`PythonSdkFlavor` detects pythons.
It uses `VirtualEnvReader` under the hood (see virtual env flavor) and system pythons (see other flavors).
We use it in `PythonLocalAddInterpreterModel` and cover it with tests
PY-74425 WIP, PY-74236: `VirtualEnvReader` shouldn't return `null` nor should it check for dir existence, use `getVEnvRootDir` as a default dir for venv.
The whole logic behind `VirtualEnvReader` is the following: we check for some env variable, and if it points to the correct path -- we use it. We fall back to the home directory otherwise.
Directory doesn't need to exist (hence, no need to check `isDirectory`) because a client might always create it.
Even worse: directory would probably not exist on a fresh OS, but a user still wants to create virtual envs there.
PY-74425 WIP: Encapsulate python names and patterns inside `VirtualEnvReader`.
`VirtualEnvReader` seems to be the main entry point to look for virtual envs on the local file system.
Historically, flavors did that, so they had a set of names and patterns to filter python by name, however:
1. `UnixPythonSdkFlavor` had named for **nix only, and `VirtualEnvSdkFlavor` had names both for Windows and **nix. It is unlikely to see a `.exe ` file on **nix or file, without an extension on Windows, so this check is useless and broken (`VirtualEnvSdkFlavor` checks for both names on both OSes)
2. `UnixPythonSdkFlavor` had regex to filter Python2, but this python was removed 4 years ago and could hardly be met on any new OS; hence this check is useless.
3. New Project Wizard needs to find pythons, but knows nothing about names and patterns.
Merge-request: IJ-MR-142040
Merged-by: Ilya Kazakevich <ilya.kazakevich@jetbrains.com>
GitOrigin-RevId: ce649b4f12f7c7b60a25d8e1fb1222e075337844
Otherwise, if someone wants to move a definition/extract a superclass from there to
a brand-new package, e.g. from main.py to pkg/mod.py, a namespace "pkg" package will
be created.
Restore the original behavior of PyExtractSuperclassTest.testMultifileNew: the origin
file was inside a regular project root without __init__.py alongside.
GitOrigin-RevId: 750414b18582740076c14bfcfd07fa38992b4428
Namely, Move Module Members, Extract Superclass and Make Local Function Top-Level were
all affected by this.
Now we check if the refactoring origin is inside a namespace package to decide whether
__init__.py should be generated for target directories.
Co-authored-by: Kamalia <alishevakamalia@gmail.com>
Co-authored-by: Maksim.Levitskii <maksim.levitskii@jetbrains.com>
GitOrigin-RevId: b0b3420c5ec8d1f7d3000d8834211631690a0c42
1. `PythonHelpersLocator` is an API to get helpers. It is aware of PyCharm Community helpers but also aware of some EP that provides additional helper paths.
2. EP implementations for PyCharm Prof and Jupyter that provide additional (prof) helpers.
It will help avoid problems with which Locator to use from Professional, Community or Jupiter plugins.
Merge-request: IJ-MR-140027
Merged-by: Egor Eliseev <Egor.Eliseev@jetbrains.com>
GitOrigin-RevId: c7c34f323247002699866f12f6ff5a08cf6a18ff
Otherwise, we end up with dozens of unintentionally public names such as "s", "i", "k"
even in the standard library (e.g. `this.s` or `pickletools.i`).
Ideally, we should rely on .pyi stubs and the content of `__all__` to offer only explicitly
exposed API, but not every module has any of those two, and it's not clear how to match
.py files and the corresponding .pyi stubs fast enough for completion.
GitOrigin-RevId: 163c472654e60ae63ff893142b8ddb9accc56393
