From a general philosophical perspective, I share Steve's view - the vast majority of potential CPython users don't want to be consuming upstream Python themselves, they want to be getting it from a redistributor.

This has nothing to do with the quality of the software itself, and everything to do with the fact that the open source meta-experience is tailored towards DIY co-collaboration, rather than producing a streamlined and completely hassle free customer experience for a given problem domain. For education, the Raspberry Pi foundation will be a better supplier than us, for data analysis, Enthought or Continuum Analytics, for Linux system management, the relevant Linux distributor.

For Windows at the moment the default supported redistribution choice is going to be ActiveState (that's certainly the one we used when I used to do professional Windows based Python development), but our upstream relationship there isn't as good as the ones we have the Linux distributors or the data analysis focused redistributors.

As Steve says, that leaves the upstream Windows installers trying to fulfil two different roles - both being something which users can install purely for their own use *and* being suitable for a corporate IT department to incorporate into a Standard Operating Environment. At the moment it's more the latter, which is also fine for users with full administrative control over their own system, but no good for restricted corporate systems.

The immediate workaround is to use the Anaconda distribution from Continuum Analytics in such cases, even if you don't need the data analysis components.

In terms of consistency with what we do on the POSIX side, the case can definitely be made that "System Python" is the right default behaviour for upstream.

The "Python-as-a-library" use case is currently a problem on both POSIX and Windows, and PEP 432 goes into several of the reasons why. There are also a host of additional issues at least on POSIX related to building extension modules, and this is one of the big reasons Continuum Analytics don't use pip natively and use conda instead - getting extension module builds to work reliably cross-platform when running from a user directory is a genuinely hard problem even if you're just linking to C libraries, let alone if you might be linking to C++ and FORTRAN libraries as well. That's a large part of why conda is on my short list of possible language independent user level package management tools to consider proposing for use in Fedora: https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement (and it's the *only* platform independent one, since Nix doesn't work on Windows)