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
It doesn't use indexes anyhow, and it's very inconvenient not to have it
available while they are being updated. It becomes especially noticeable with
"Idle Indexing" plugin that postpones the indexing on startup.
GitOrigin-RevId: 78dbe4399a38376ae519025e7bbe09906a7d0905
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
* Call ProgressManager.checkCancelled() more often.
* Retrieve PSI elements from the index one-by-one, not all at once.
* Filter out duplicate suggestions on the go, don't accumulate them only to
iterate all over again.
* Don't use this completion for empty prefixes. It's painfully slow and not
very useful. Instead, it's now automatically restarted as soon as at least some
prefix appears.
GitOrigin-RevId: 915c5986dbbfc975ce5f43696b15c23f8febc7f2
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
Firstly match protocol usage against its definition, then match type against protocol definition.
This way allows to get correct substitutions.
GitOrigin-RevId: 3565be1dc2991b6b55be666404e5e4715a3e3e80
Now PyCharm successfully parses var with type hinting and
correctly resolve types of function parameters
GitOrigin-RevId: 8baa06c912f5586bb60e6a03d6bad068107ffff6
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
