[Python-ideas] PEP 420: implicit namespace sub-package
barry at python.org
Tue Sep 11 20:33:00 EDT 2018
Gallian Colombeau wrote on 8/27/18 06:49:
> As I understand, for a package to allow being extended in this way, it
> must be a namespace package and not contain a marker file. As a matter
> of fact, no sub-package until the top level package can have a marker file:
No, that's not true.
> However, what is not discussed is "implicit namespace sub-package". In
There really is no such thing. Packages are either PEP 420 style
namespace packages, or regular packages. The latter contain __init__.py
The language reference goes into quite a bit of detail on the matter.
> Python 3.6 (I guess since the first implementation), if you have this
> parent # Regular package
> child # Namespace package
> you get "parent" as a regular package and "parent.child" as a namespace
> package and it works (although now, every package data directory became
> namespace packages and are importable, which may or may not be
> desirable). The point is, does that add any value?
Personally, I don't think so. You can do it, but it's not the intended
purpose, so you're on your own.
> I wasn't able to find
> any discussion about this and, as far as I can see, there is actually no
> use case for this as there is no possible way to contribute to the
> "parent.child" namespace. Is that an intended behavior of PEP 420?
There can be use cases for subpackage namespace packages, although they
are definitely more rare than top-level namespace packages. One
possibility would be a plugin system, say for application 'foo', where
they reserve a subpackage for separate-distribution plugins, E.g.
foo.plugins.ext where foo/plugins/ext has no __init__.py file.
> Wouldn't it be more appropriate to enforce a sub-package to be a regular
> package if the parent package is a regular package?
As Brett says, it's probably way too late to change this.
More information about the Python-ideas