On 14 July 2013 16:43, Donald Stufft <donald@stufft.io> wrote:

I just want to make sure that the boundaries between the governance of Python and pip are clearly defined and the expectations on both sides are laid out and agreed upon before it happens. And I think this raises a good point about how the two projects are going to interact.

Agreed, I think the boundaries need to be clear. If something installed by default is *only* support code for a bundled application, then it should either adhere to the standard library's backwards compatibility policies (by appropriately marking private APIs as private), or else it should issue a warning when imported by any other application. Either of those options sounds good to me.

However, I consider expecting people to "just know" (or to look at documentation to determine) which provided modules are public or private without adhering to standard naming conventions or providing an explicit runtime warning to be unreasonable.

(and yes, if "pip" goes down the runtime warning path, we should probably look into providing a runtime warning for at least the "test" namespace and possibly even the "idlelib" namespace, too)