Re: PEP 420: Implicit Namespace Packages

On Sat, May 5, 2012 at 8:33 PM, Antoine Pitrou <[email protected]> wrote:
> If anything, I'd like to see data points about these "current version
> control systems" being "pretty abysmal [!] when it comes to coping
> with directory renames".

It's really irrelevant. The real deciding factor is that Guido didn't
like the scheme proposed in PEP 382, so he rejected it.

However, my personal experience with both git and hg is that renaming
files still generates an awful lot of diff noise - none of them have
formal rename, they still fake it with "remove and add" the same way
subversion does. "abysmal" is really too strong a word (they're much
better than CVS), but it's still a far cry from formal rename
tracking.

Since we *want* people to eventually drop their custom namespace
package systems in favour of the standard one, it makes sense to make
the migration path as smooth as possible. Requiring people to do a
mass rename of files makes it unnecessarily difficult for them to make
that transition.

> This doesn't address PEP 420's issues, which will still come to bite us
> in 10 years: the potential for confusion, the weirdness of the lookup
> algorithm.

Believe me, I sympathise - PEP 420 getting accepted is going to mean I
have to make some fairly major changes to PEP 395 before I can propose
it for 3.4. However, the proposed mechanism in PEP 420 basically just
brings Python's import system into line with the way that C, Java,
Perl, etc all already work, so I predict the "maintenance and support
issues for the future" as a result of this change aren't going to be
severe (particularly once I revise PEP 395 to be primarily a proposal
for better error reporting in various error cases relating to
__main__). I've also started Tools/scripts/import_diagnostics.py -
initially just to help me while trying to eliminate the
_frozen_importlib vs importlib._bootstrap duplication, but longer term
I hope to see some more sophisticated commands get added so that
people can easily get better info if their imports start doing strange
things.

After the last discussion, I now believe that accepting *either* PEP
382 or 420 will lead to an acceptable long term outcome. While my own
preferences still favour the explicit approach in PEP 382, I can also
acknowledge that PEP 420 has its own attractive features, most notably
that it:
- is more consistent with the module systems of other languages
- has a greater chance of completely displacing existing namespace
package mechanisms in the long term
- is significantly more intuitive than PEP 382, since almost nothing
else uses directory extensions, so any scheme relying on them is going
to feel awkward and unintuitive to beginners and veterans alike (and
we can't use a shared marker file, since getting rid of __init__.py is
the entire point of these PEPs, and using a *set* of marker files with
a common extension clutters the filesystem and means we have to do
pattern matching on directory listings during import instead of being
able to use simple stat calls and exact string matches).

Cheers,
Nick.

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