[Python-ideas] "Regular" namespace packages

[Dmitry Malinovsky]

Thank you, Guido, however the whole idea is to avoid modifying "first"
package, so the "first" package author can freely leave his "first"
namespace for extensions developers without even knowing that such
extensions exist.

On Tue, Mar 10, 2015 at 10:14 PM, Guido van Rossum <guido at python.org> wrote:

> 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)
>



-- 
Dmitry Malinovsky
Support Engineer
Thumbtack Technology
Email: dmalinovsky at thumbtack.net <pnegoduyko at thumbtack.net>
Skype: d_malinoff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150310/7d7d631a/attachment.html>