Re: PEP 420: Implicit Namespace Packages

On Sat, 5 May 2012 22:12:51 +1000
Nick Coghlan <[email protected]> wrote:
> 
> 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.

That doesn't seem to make any difference in practice:

$ cat a
a\nb\n
$ hg mv a b
$ hg di 
diff --git a/a b/b
rename from a
rename to b

(there's no "awful lot of diff noise" above)

> "abysmal" is really too strong a word (they're much
> better than CVS), but it's still a far cry from formal rename
> tracking.

Well, you should come up with well-defined situations where this is
a problem, or you are making a purity argument.

(I'm still baffled that FUD about VCS capabilities has a weight in the
discussion of a Python PEP; yes, they're much better than CVS :-))

> Requiring people to do a
> mass rename of files makes it unnecessarily difficult for them to make
> that transition.

Renaming a directory should not be "unnecessarily difficult" by any
stretch of the word, especially for a developer of something as large
as a project requiring namespace packages.

Any x.y -> x.y+1 transition is harder than renaming a directory for any
such large Python project.

> 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

Python's import system is different from these languages', so the
implications are not the same either. The very fact that PEP 420 has to
propose a deferred detection of namespace packages compared to other
kinds of importable objects (modules, packages) proves it.

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

"clutters the filesystem"? We're talking about a little-used feature
here.

As for "simple stat calls" instead of "directory listings", I suggest
you take a look at current importlib, because it uses directory
listings in order to avoid stat calls :-)

Regards

Antoine.