[zahlman]

>If only because making "implicit" explicit is linguistically pointless in that 3-word phrase.

"Implicit" isn't part of the formal terminology PEP 420 introduces. It's just in the title and some other passing descriptive mentions. (The PEP author has posted ITT, so you could probably ask for details.)

>Either "namespace" or "package" is also pointless linguistically.

"Namespace package" distinguishes from "regular package". The two words are not at all synonyms. In Python, "namespace" could also plausibly refer to the set of attributes of an object (actually how package namespacing is implemented: the package is a `module` object, and its contained modules and subpackages are attributes), keys of a dictionary, or names in a variable scope (e.g. "the global namespace" - which, in turn, gets reflected as a dictionary by `globals()`). Meanwhile, a package in a running program is about more than the namespacing it provides: it has additional magic like `__path__`. And in a broader development context, "package" could refer to a distribution package you get from PyPI, which might contain the code for zero or more "import packages" (yes, that is also quasi-standard terminology: https://packaging.python.org/en/latest/discussions/distribut...).

>Packages and "implicit namespace packages" are not substitutes for one another (fscking parent relative imports!)

Yes, they are. Both are modeled with objects of the same type in Python, created following the same rules. The absence of `__init__.py` is not why your relative imports fail. They fail because the parent package hasn't been loaded (and thus its `__path__` can't be consulted), which happens because:

1. you've tried to run the child directly, rather than entering the package via an absolute import (from a driver script or by using `-m` - see https://stackoverflow.com/questions/11536764); or

2. you're expecting the leading `.`s in a relative import to ascend through the file hierarchy, but it doesn't work that way - they ascend through the loaded package hierarchy (https://stackoverflow.com/questions/30669474).

(The SO references are admittedly not great - they're full of bad answers from people who didn't properly understand the topic but managed to get something working. Hopefully I'll have much better Q&A about this topic up on Codidact eventually.)

I do relative imports without `__init__.py` all the time. Here's a demo:

    $ mkdir package
    $ mkdir package/subpackage
    $ cat > package/parent.py
    print("hello from parent")
    $ cat > package/subpackage/child.py
    from .. import parent
    print("hello from child")
    $ python package/subpackage/child.py 
    [traceback omitted]
    ImportError: attempted relative import with no known parent package
    $ python -m package.subpackage.child
    hello from parent
    hello from child
    $ cd package/
    $ python -m subpackage.child
    [traceback omitted]
    ImportError: attempted relative import beyond top-level package

Adding `__init__.py` files has no effect on this.

[RhysU]

Thank you for the extensive response.

Paraphrasing, "That's not the name it's just the title and used repeatedly therein" seems to cause more than a little confusion.

The extensive response confirms that the words are awfully overloaded in subtle ways, and that using "namespace" as an adjective was a poor choice.

As for your example, thank you. I forget the specific edge case that trips me up here. But, rest assured, I will re-encounter it.

[zahlman]

>Paraphrasing, "That's not the name it's just the title and used repeatedly therein" seems to cause more than a little confusion.

The phrase "implicit namespace packages" is only used once within the prose of the PEP. But also, the title of the PEP is certainly a separate thing from the name of the feature.

Similarly, nobody says that a project following modern packaging standards is using "A build-system independent format for source trees" (which would make it sound as if there were more than one relevant such format), the title of PEP-517. Instead they say that it's a `pyproject.toml`-based project.

>The extensive response confirms that the words are awfully overloaded in subtle ways,

I agree, basically. This happens all the time in programming, of course. "Package" in the Python ecosystem is perhaps not as bad as, say, `static` in the C++ language; but it's bad and I really wish there were a reasonable way to fix it.

On the other hand, "namespace" here isn't meant as Python-specific jargon. It isn't really meant that way anywhere else, either (e.g. people saying "global namespace" should normally really be saying "global scope"). It's the language of computer science, in the abstract (https://en.wikipedia.org/wiki/Namespace). So of course it ends up referring to all kinds of things (in multiple categories: data types, objects which are instances of those data types, file systems...) which implement the concept of namespacing.

>But, rest assured, I will re-encounter it.

Whenever I browse HN I mainly look for posts about Python specifically; so if for example you ever have an Ask HN about it there's a good chance I can help.

[RhysU]

Thank you.