The cache of resolved qualified names is not context aware, so it's not safe to
keep such results in it. The legacy same directory imports in Python 2 have
already been taken into account and excluded, but we forgot to do the same for
recently enabled same directory imports in Python 3 project sources.
GitOrigin-RevId: f8885543ffa34ea652368a4f190210439173bdfc
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
Modules list has been updated using python on Windows, seems it should be done on all OSes and merged.
GitOrigin-RevId: 621172608fffddc3e830f1133fba89a05d092eba
Debugger tests are slow and fragile, so we move them into different config.
See .xml files in ``runConfigurations`` folder
GitOrigin-RevId: 0de6686314567c2028432a1071fddfd8fe69d0b8
We shouldn't have used function's presentation there to check it's uniqueness,
it includes parameters that we rightfully don't include in the lookup string as
not affecting the import path anyhow.
GitOrigin-RevId: 29c5d231182afb5ebbf71787baea1cd292d82370
I also changed the implementation so that only the very first tokens of
declarations are considered as anchors for method separators. Otherwise,
they start to flicker as their corresponding class and function elements
are often not re-evaluated by LineMarkerProviders on changes in a document.
GitOrigin-RevId: 90488c4bd1c662634c4b6681ce78b1b64c503782
If docorated function has a parameter and the decorator has
an argument with the same name as the parameter then we must not rename
the argument in case of renaming the parameter.
GitOrigin-RevId: ebc5dcf7448080e2762004a2779cd06700c042a8
To avoid possible confusion regarding its target element, the intention is now
suggested only when the caret is inside a literal part of an f-string, not at
any expression it contains.
The conversion affects only the string on which the action was invoked,
including ones in its inner expressions, but not enclosing f-strings. Hence,
converting quotes for an f-string might also change quotes of its inner strings
to preserve the syntactic correctness. Converting quotes for an inner
strings, on the other hand, is possible only if it won't break their parent
f-strings.
GitOrigin-RevId: fb997ac8e26eea728897820f0d94bd84aa9e4491
Namely, if such composed literal has nodes with different quotes, convert only
the one directly under the caret. This way we both preserve the old behavior,
when quotes of all individual strings of the literal were converted, and allow
to convert quotes of at least one element if that is not possible.
I've also migrated the intention to newer PyStringElement API that appeared with
the new f-string support.
GitOrigin-RevId: a8592a46e2991b172a205f041cbc3b668e242e8a
The issue itself was fixed, together with PY-32864, in
931d1ea4c09d145e763aed839dcb4acbb3e43ec7.
GitOrigin-RevId: af02861b24165da22722e2ad7891dc674a944472
