[Import-SIG] PEP 420: Implicit Namespace Packages
solipsis at pitrou.net
Sat May 5 14:32:26 CEST 2012
On Sat, 5 May 2012 22:12:51 +1000
Nick Coghlan <ncoghlan at gmail.com> 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
$ 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
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
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
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 :-)
More information about the Import-SIG