Re: PEP 420: Implicit Namespace Packages

On Sat, May 5, 2012 at 8:47 AM, Antoine Pitrou <[email protected]> wrote:
> Unless there are clear advantages over PEP 382, I'm -1 on this PEP, and
> would like to see PEP 382 revived.

I raised this question as well, and the PEP as written doesn't do a
great job of summarising the thread that addressed it.

There were two counterpoints raised that I found compelling:

A. Guido simply doesn't like directory extensions. I have to agree
with him that using them to handle packaging would be a weird and
unusual approach, and, well, he *does* get to play the BDFL card in
cases like this.

B. Current version control systems are still pretty abysmal when it
comes to coping with directory renames, and we want to avoid
unnecessary stumbling blocks on the migration path from the current
pkgutil.extend_path() based namespace packages to the new native
system.

With PEP 382, the migration path is:
1. delete all __init__.py files from namespace package portions
2. rename the directories for all namespace package portions to append
the ".pyp" extension

With PEP 420, the migration path is:
1. delete all __init__.py files from namespace package portions
2. there is no step 2

The extra step required by the PEP 382 approach is exactly the kind of
pointless revision history noise that PEP 414's reintroduction of
explicit Unicode literals is designed to eliminate from Python 2 to
Python 3 migrations.

Between "Guido doesn't like directory suffixes" and "version control
systems are still fairly bad at handling directory renames", I changed
my own opinion on PEP 420 from -1 to +0. If we'd been starting from a
clean slate with no language history or migration of existing projects
to account for, then my opinion would be different, but given where we
are today, I find the pragmatic argument in favour of simply losing
the explicit markers compelling.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia