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
Previous synchronization of background updates in PythonSdkUpdater was flawed.
It didn't prevent us from launching several concurrent updates for the same
SDK, but only blocked subsequent refresh tasks on a BlockingSet, still showing
the corresponding progress indicators, piling up threads and exhausting system
resources.
The new implementation attempts to enforce the following policy: no two updates
for the same SDK can be run concurrently, and all subsequent updates for an SDK
already being refreshed are squashed and queued to be executed once it finished.
We also adjusted PythonSdkUpdater interface to better indicate synchronization
of individual methods. The old update() method, which performed a few of update
operations in a blocking fashion, is now deprecated and replaced with more
explicit scheduleUpdate(), always asynchronous, and internal
updateVersionAndPathsSynchronouslyAndScheduleRemaining() that replicates the old
behavior for the time being due to a number of existing usages, but is to be
revised. Synchronous version and paths refreshes are now performed under a modal
progress indicator.
The legacy updating mechanism can be restored as a fallback if
"python.use.new.sdk.updater" Registry flag is reset.
Additionally, internal PyUpdateProjectSdk action was added for diagnostic.
These changes are a result of a joint effort with Alexey Kniazev.
GitOrigin-RevId: 6260cda7a22c4f5932f7d78eb6660a50e2b972b6
