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
files.
The language reference goes into quite a bit of detail on the matter.
https://docs.python.org/3/reference/import.html#packages
Python 3.6 (I guess since the first implementation), if you have this
layout:
Lib/test/namespace_pkgs
project1
parent # Regular package
__init__.py
child # Namespace package
one.py
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.
-Barry
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
