PEP 420: implicit namespace sub-package
Hello, the PEP 420 (Implicit Namespace Packages) is quite descriptive about the problem and the solution implemented back in Python 3.3 but I feel there may be a part missing (but maybe this is categorized as an implementation detail). 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: Lib/test/namespace_pkgs project1 parent child one.py project2 parent child two.py However, what is not discussed is "implicit namespace sub-package". In 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? 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? Again, I may have missed something or misinterpreted PEP 420 but this contributes to the "Implicit package directories introduce ambiguity into file system layouts." point by Nick Coghlan that was supposed to be addressed in PEP 395. Wouldn't it be more appropriate to enforce a sub-package to be a regular package if the parent package is a regular package? Gallian -- *Gallian Colombeau * *Software engineer * hiphen-plant-logo <http://www.hiphen-plant.com> *Centre INRA PACA - UMR EMMAH* /228, route de l'aérodrome - CS 40509 84914 Avignon - Cedex 9 - France / www.hiphen-plant.com
Basically it's too late to change this as I'm sure there's code out there somehow relying on these semantics. Plus the potential harm from someone accidentally having a namespace like this is negligible at best. But there is possible value if you mutate __path__ to have multiple entries and you want a namespace package for a sub-package. On Mon, 27 Aug 2018 at 06:50 Gallian Colombeau <gcolombeau@hiphen-plant.com> wrote:
Gallian Colombeau wrote on 8/27/18 06:49:
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
Personally, I don't think so. You can do it, but it's not the intended purpose, so you're on your own.
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
Basically it's too late to change this as I'm sure there's code out there somehow relying on these semantics. Plus the potential harm from someone accidentally having a namespace like this is negligible at best. But there is possible value if you mutate __path__ to have multiple entries and you want a namespace package for a sub-package. On Mon, 27 Aug 2018 at 06:50 Gallian Colombeau <gcolombeau@hiphen-plant.com> wrote:
Gallian Colombeau wrote on 8/27/18 06:49:
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
Personally, I don't think so. You can do it, but it's not the intended purpose, so you're on your own.
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
participants (3)
-
Barry Warsaw -
Brett Cannon -
Gallian Colombeau