On Thu, Jul 11, 2013 at 10:29 AM, Daniel Holth <dholth@gmail.com> wrote:
On Thu, Jul 11, 2013 at 9:33 AM, Paul Moore <p.f.moore@gmail.com> wrote:
> On 11 July 2013 13:49, Brett Cannon <brett@python.org> wrote:
>>
>> The dead-simple, extremely elegant solution (starting in Python 3.4) is to
>> make pip a namespace package in the stdlib with nothing more than a
>> __main__.py file that installs pip; no checking if it's installed and then
>> running it, etc, just blindly install pip. Then, if you install pip as a
>> regular package, it takes precedence and what's in the stdlib is completely
>> ignored (this helps with any possible staleness with the stdlib's bootstrap
>> script vs. what's in pip, etc.). You don't even need to change the
>> __main__.py in pip as it stands today since namespace packages only work if
>> no regular package is found.
>
>
> Wow - that is exceptionally cool. I had never realised namespace packages
> would work like this.

Not exceptionally cool ... and that's why the namespace_package form
is popular, since the first package in a set of namespace packages
that gets it wrong breaks everything.

I'm really not following that sentence. You are saying the idea is bad, but is that in general or for this specific case? And you say it's popular because people get it wrong which breaks everything?

And how can namespace packages be popular if they are new to Python 3.3 (the ability to execute them with -m is new in Python 3.4)? Are you talking about pkgutil's extend_path hack because I'm talking about NamespaceLoader in importlib?

I'm just not seeing the downside. We control the stdlib and pip, so we know the expected interaction and we are purposefully using the override mechanics so it's not going to get messed up by us if we consciously use it (and obviously have tests for it).