[Python-ideas] "Regular" namespace packages

Guido van Rossum guido at python.org
Tue Mar 10 17:14:59 CET 2015


Your example code can be corrected by updating first.__path__:

first.__path__.append('second/first')

Now "import first.second" will succeed.

On Tue, Mar 10, 2015 at 8:43 AM, Dmitry Malinovsky <
dmalinovsky at thumbtack.net> wrote:

> Hello,
>
> I'm implementing an extensible library. Along with the library itself I
> want to implement various extensions (and some of these extensions will be
> also pluggable).
>
> I found that creating a namespace package will be user-friendly (to
> distinguish default implementations from third-party ones).
> However, current namespace packages implementation does not allow me to
> have a dedicated regular package with the same name as the namespace.
> E.g. if I have to namespaced packages: top.packageA and top.packageB, I
> can't have dedicated top package.
> (Actually, I can do that: py module is the example, but this way is not
> easy to implement for the library developers and to understand
> by external contributors).
>
> So my idea is to have a standard (and easy) way to declare a package which
> can act both as a namespace package and a regular package,
> like pep-420 (implicit namespace packages) standardized way to create
> namespace packages.
>
> Here is an example:
>
> first/first/__init__.py:
> X = 1
>
> second/first/second/__init__.py:
> Y = 2
>
> import sys
> sys.path += ['first', 'second']
>
> import first
> first.X  # 1
> import first.second  # I expect to get 2,
> first.second.Y         # but currently ImportError is raised
>
> If I understand this correctly, this change will require to modify the
> default submodule lookup algorithm,
> so when the import machinery finds the cached first module, and there is
> no second submodule defined,
> the machinery launches the standard namespace packages finder algorithm
> (as described in [1]),
> excluding first package directory from the search path.
>
> From a user perspective, assuming we have a mature library with lots of
> extensions (for example, flask),
> and a pluggable extension (like flask-flatpages), the following imports
>
> from flask import Flask
> from flask_flatpages import FlatPages
> from flask_flatpages_knitr import FlatPagesKnitr
>
> can be rewritten as follows:
>
> from flask import Flask
> from flask.flatpages import FlatPages
> from flask.flatpages.knitr import FlatPagesKnitr
>
> which I find more readable than the first snippet.
>
> What do you think about it? Is flat better than nested, or namespaces are
> really great?
>
> Thank you for any feedback!
>
> [1] https://www.python.org/dev/peps/pep-0420/#dynamic-path-computation
>
> --
> Dmitry Malinovsky
> Senior DevOps
> Thumbtack Technology
> Email: dmalinovsky at thumbtack.net <pnegoduyko at thumbtack.net>
> Skype: d_malinoff
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150310/d22de36d/attachment.html>


More information about the Python-ideas mailing list