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

[Guido van Rossum]

-1. It would create a very busy toplevel directory. There's a reason
people nest directories...

On Sun, May 13, 2012 at 6:18 AM, Benoît Bryon <benoit at marmelune.net> wrote:
> -------- 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
>>
>
> _______________________________________________
> Import-SIG mailing list
> Import-SIG at python.org
> http://mail.python.org/mailman/listinfo/import-sig



-- 
--Guido van Rossum (python.org/~guido)