[Import-SIG] Fwd: Re: Proposal and questions about PEP 420

[Benoît Bryon]

-------- Original Message --------
Subject: Re: Proposal and questions about PEP 420
Date: Sun, 13 May 2012 08:10:53 -0400
From: "Eric V. Smith" <eric at trueblade.com>
To: Benoît Bryon <benoit at marmelune.net>

Hi, Benoit.

This hasn't been specifically discussed. Part of the rejection of PEP
382 was due to dots in the names of directories, but as directory
extensions (foo.pyp). I'm not sure if this concern would also apply to
your proposal.

Also, I'm not sure how common nested namespace packages are. I know 
I've
never run across them.

That said, I think you should post this idea to the import-sig mailing
list, and see what others think.

Eric.

On 5/13/2012 7:31 AM, Benoît Bryon wrote:
> Hi,
> 
> I just read PEP 420 about namespace packages, and I wonder if the
> following points have been considered...
> 
> .. note::
> 
>   I'm asking you because PEP 1 tells:
> 
>   >  When in doubt about where to send your changes, please check first
>   >  with the PEP author and/or PEP editor.
> 
> 
> Has the following proposal been considered or refused?
> 
> As an example, to implement foo.bar and foo.baz namespaces:
> 
> ::
> 
>   somewhere-in-sys.path
>   ├── foo.bar
>   │   └── __init__.py
>   └── foo.baz
>       └── __init__.py
> 
> I mean:
> 
> * since "namespace" directories have to be empty, we can get rid of them.
> * a namespace package would be "some directory with at least a dot in
>   the name".
> 
> 
> As import machinery
> ===================
> 
> * It's easy to guess that "foo.bar.baz.other" is a package in
>   "foo.bar.baz" namespace.
> * It's flat.
> * It's quick to scan: no loops within "foo/" folder(s), only one disk
>   access to read an unique __init__.py.
> 
> 
> As a developer
> ==============
> 
> As a developer, when I edit namespace packages, I have to deal with
> nested empty directories.
> As an example, here is a repository layout to edit some foo.bar.baz
> package with PEP-420:
> 
> ::
> 
>   path-to-python-foobarbaz/
>   ├── setup.py
>   ├── README
>   └── foo
>       └── bar
>           └── baz
>               └── __init__.py
> 
> .. note::
> 
>   With current namespace packages implementation, foo/ and foo/bar/
>   contain an __init__.py
> 
> * We never edit foo/ and foo/bar/. They are empty. They contain nothing
>   valuable.
> * When one sees package root folder, he cannot guess that foo/ is a
>   namespace package.
> * To new Python users, it's not clear that foo/ must be empty (or must
>   contain only a "constant" __init__.py).
> * It seems that many developers actually don't use namespace packages
>   because it's implementation is not flat.
>   As an example, I personally know some Django users who argue that
>   "Flat is better than nested" wins over "Namespaces are one honking
>   great idea -- let's do more of those!".
>   Since "more namespaces" currently means "more nested directories", we
>   can't convince these users to implement namespace packages.
> 
> With "directories with dots in their names" proposal:
> 
> ::
> 
>   path-to-python-foobarbaz/
>   ├── setup.py
>   ├── README
>   └── foo.bar.baz
>       └── __init__.py
> 
> * it's flat.
> * it's easy to guess that "foo.bar.baz" is a namespace package.
> * impossible to write code in foo/ folder or alter foo/__init__.py:
>   "foo" is not a classic module, it is a namespace.
> * respects both "Flat is better than nested" **and** "Namespaces are one
>   honking great idea -- let's do more of those!". So it may attract
>   developers and maybe more namespaces would be created.
> 
> 
> Regards,
> 
> -- 
> Benoit Bryon
>