There are 3 types of directories: plain directories, ordinary packages (with
__init__.py) and PEP 420 namespace packages. There are 3 types of imports:
absolute (from a root), same directory (absolute import from the current
directory when it's not explicitly marked as a root) and relative imports
(imports that start with dot).
Absolute imports are correct in all kinds of directories.
Same directory imports are correct in Python 2 in all cases and in Python 3 if
we have the directory containing the script with this import in Python path at
runtime. Users of Python 3 often face the problem when they can run the script
from the console because the directory containing this script got into Python
path but still have red underline and an unresolved reference error in the same
directory import because PyCharm didn't know that this file will be used as a
program's entry point. Previously, the way to fix such a problem was marking it
as a source root. But this action was not so obvious, especially for newcomers.
With this feature, such imports resolve successfully and now it is not necessary
to mark directories as source roots.
Relative imports are correct only in Python 3 namespace or ordinary packages and
should not be used in plain directories. If we have a relative import in plain
directory we highlight it with a weak warning and suggest 2 ways of fixing that:
marking directory as a namespace package explicitly (with quick fix or with Mark
As | Namespace Package) or changing this import to the same directory import
with a quickfix or manually.
Explicitly marking namespace packages can later be used for automatically
running files from them and ordinary packages with "-m".
The new resolve policy and explicit namespace packages can be disabled with the
Registry flag "python.explicit.namespace.packages".
These changes also address PY-40396. Namely, now any directory with __init__.py
inside or explicitly marked as a namespace package has a package icon,
regardless of its name or parents.
GitOrigin-RevId: 310fa562eb60121243cb6d68386ffc3e45c73245
Both typing.TypeAlias (available only in 3.10) and typing_extensions.TypeAlias
names are supported.
RHS values of assignments annotated with TypeAlias are always retained in
stubs and injected into (if it's a string literal), regardless of whether
they look similar to a well-formed type hint. It seems natural to assume
that if a user employs such as specific marker as "TypeAlias" at all, they
clearly indicate that the value is supposed to be a type.
The inspections "Type hints definitions and usages" and "Final classes, methods
and variables" properly analyse RHS of assignments annotated with TypeAlias.
Type hinting inspection also reports illegal usages of TypeAlias, as it was
done for other special forms in the typing module.
The type of such variables themselves is Any, however they're still displayed
as having the type "TypeAlias" in Quick Documentation to avoid confusion.
GitOrigin-RevId: fab02f6e1060c0994e1d21201768e7b28ba7d9e0
* SpecifyTypeInPy3AnnotationsIntention
* ImportFromToImportIntention
* ImportToggleAliasIntention
* ImportToImportFromIntention
* PyGenerateDocstringIntention
* SpecifyTypeInDocstringIntention
Some of them were additionally simplified by replacing their custom
field for an intention's name with the inherited one.
GitOrigin-RevId: 72e4c1b5fe628eca36496d56396ee9e149f5104f
Some inspection had duplicated messages for their names. Normalized those
to use "INSP.NAME" keys for that purpose and removed unused copies.
Also, one of the messages was used only in a test commented ten years ago.
Got rid of that and the corresponding test data.
GitOrigin-RevId: c859370a8b62079e9e345cd03386da850de28586
Get rid of PyNamedTupleType.DefinitionLevel (finally) and PyOverridingTypeProvider.
PyNamedTupleType is updated here since otherwise we would have to provide parameters for PyNamedTupleType with NT_FUNCTION as a definition level via PyNamedTupleType.getParameters.
Update NumpyDocStringTypeProvider and numpy test data, otherwise it will return `numpy.core.ufunc` as a type for every function having special name.
See NumpyDocStringTypeProvider.getReferenceType.
Return accidentally lost behaviour in PyiUtil.findSimilarElement for classes: don't look for similar element in ancestors.
GitOrigin-RevId: e2410eaa0e0cd5f98e4a86515b4358c140b373e6
All its warnings are extracted into the bundle, but they are still poorly
adapted for translation. Each of them in constructed from two separate
messages, a common prefix and an individual feature description, with negation
of the main verb being split. Only the first message can vary depending on
the affected versions number, but both parts of the verb need to agree in many
languages other than English. It's not clear how to address it without
overhauling inspection internals, thus it will be revised later.
I also slightly updated the warnings format. Namely, put "version" in plural,
if a warning applies to multiple Python versions, and removed trailing periods
from single-sentence messages.
GitOrigin-RevId: 51e577201b11fb4e8b6967e1f5ad27143ba9f82e
No more PyDocstringFile for them since doctest and type comments should be parsed differently (at least `...` should not be skipped)
GitOrigin-RevId: 9b78ad0491859dbf381a049e93ac74bc83db4183
The main idea here is that we also automatically convert the containing string
literal into a proper f-string upon selecting one of such variants.
Hopefully, it addresses the common problem of forgetting to add "f" prefix
before an interpolated (in mind) string literal in a more discoverable fashion
than a dedicated intention or a postfix template would.
GitOrigin-RevId: f59065abeb4a3b0cd7a0de42c9c06c9fad318b19
Also, mark them as @ApiStatus.Internal instead of @Deprecated. These EP however
won't be safe to use as soon as we decide, e.g. to extract Django support into
a standalone plugin, because unloading it won't trigger rebuilding of indexes
in the current implementation leaving unused custom data in them.
GitOrigin-RevId: 3dbe4bee616c500409a088b825e3252615167069
by moving the registration of stub implementations for code-insight bridge services
from PythonPsiImpl.xml down to PythonAnalysisToolPlugin.xml where they are actually
used. All the other products using PythonPsiImpl.xml seem to include it via
python-core-common.xml, so each of them will safely get the real *ServiceImpl
implementation of the corresponding bridge.
GitOrigin-RevId: 2cf83ab8ff99efcc9ed432634e4f2d614a18cc8b
