Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Clarification about how to implement namespace packages (as in PEP 420) via import hooks for PEP 660 use case #92054

Open
Labels
@abravalheri

Description

@abravalheri

This is a follow up of 2 previous discussions in the Python discourse and an issue inpypa/packaging-problems:

Summary

One of the popular ways of implementing PEP 660 is via import hooks (since other alternatives likesymlinking package folders are not available in all platforms).

However the reference implementationeditables currently does not support namespaces.
Specifically thedynamic path computation aspect of PEP 420 is a challenge.

After inspecting the implementation forimportlib._bootstrap_external, I may have managed to find 2 solutions for this problem, described in the detail inthis discourse post and demonstrated as a PoC inthis gist:

  • Solution A: Create a custom "path class" that tries to emulate the_NamespacePath behaviour.
  • Solution B: Create a customPathEntryFinder and add a “bogus” entry tosys.path just to trigger it (implicitly relying thatimportlib.machinery.PathFinder will take care of setting__path__ to_NamespacePath object under the hood).

However, the problem is that I don't know if these approaches are reliable in the long run and in accordance with the language specification.

Open Questions

Questions like the following are still not clear to me:

  1. Is there a chance that an internal check for namespace packages will fail if__path__ uses a custom class instead of_NamespacePath even if the behaviour described in PEP 420 is observed?
  2. Can we rely on the fact that the import machinery will automatically set the namespace loader for specs in the form ofModuleSpec("name", None, is_package=True)?
  3. Ispkgutil (and particularlypkgutil.extend_path) still considered first class citizen of the standard library or is it better to avoid it when writing new code?
  4. Can we rely on the behaviour ofsys.path_hooks +importlib.machinery.PathFinder to createModuleSpec objects for namespaces that will automatically perform dynamic path computation? Or is this an internal implementation detail that can change in the future?

If the discussed approaches are not recommended, how can we support namespace packages using import hooks and deliver a complete solution for PEP 660?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp