OK, but I’m talking specifically about my experience in consultancies for which individual consultants can use “whatever helps to get things done” but corporate support is only for specific “core products” - typically big ERP systems and similar. In those environments, core IT policy can be fairly weird (and yes, it’s often dysfunctional). I’ve never seen a case where regular installers were blocked (and I can’t imagine such a policy working in that environment). Blocking the Windows Store is typically part of limiting the base Windows OS build, but consultants generally have broad capabilities over their own PCs - so installers work fine, as long as you can download them via the (centrally configured) browser. Almost no “development tools” are provided centrally - even getting a text editor other than Notepad can involve finding and installing your own
These sorts of environment are a major example of where Python (as an automation and data analysis tool) can provide significant added value (I know, I’ve given internal presentations with precisely this message) while being almost completely unsupported by the IT policy.
The target audience here is consultants who will simply ignore Python if it’s hard to set up. They’ll use R, or even Excel, for data analysis, and shell scripts or Perl for automation. Instead of the message being “Python is a great tool” it will be “data analysis is great, here’s R Studio or Excel” or “devops is the new big thing, and it’s about writing shell scripts”.
Personally, I think that getting Python into the hands of users like this is essential, and having a simple and effective “download and install” way that people can just get on with using Python is key to that. And yes, I imagine you’ll respond with “use conda for that”. I tried. People weren’t interested, because too much example Python material on the web assumes pip/virtualenv/PyPI and my target audience can’t translate that into conda terms without help that they don’t have the means to get. Also, do we really want to go back to a situation where Windows users feel like second class citizens, because all of the instructions written for and by Unix users that discuss virtualenv, pip and PyPI “doesn’t cover Windows, which uses conda”?
(Evangelism mode off )
I agree we already have too many options. But otherwise, that does indeed sound like a good solution. Unfortunately, I no longer work at my previous employer, so I can’t experiment to see whether MSIX installers are blocked along with the Store, but I suspect not, based on experience.
I agree with Steve that this is a process issue in the company, but it is something I’m very familiar with personally and anecdotally talking to others, it usually goes something like this:
Central IT department are given requirement to lock everything down
Central IT block as much as they can until they are told it’s an unworkable environment, e,g: Windows Store, many other windows features, allow listed Internet access, running arbitary executables, etc.
The majority of users can manage this but those requiring development tools can not
No policy is in place to handle this user set, so instead they get exceptions to install their own tools
These users are left unable to access useful Windows dev features like WSL, Windows store etc., but they can manually download and install Python from python.org
At a previous company 32 bit Python was popular (and the main used version). They would basically copy paste the Python directory from host to host (starting many years ago).
Certain teams would write tools and say they only validated that Python directory, others would close bugs as won’t fix if another Python (or even x64 Python with the same version) was used.
I could picture that same group of people refusing to ‘validate’ a x64 Python today and hanging on to 32 bit, even if they decided to update the golden folder to ‘minimize the impact of change’.
I would imagine plenty of other enterprise environments have similar experiences.
I have encountered some secondary schools where they had to use older versions of Windows (such as Windows 7 or even XP) due to outdated hardware. In such cases, their administrators tended to opt for a complete 32-bit environment, including CPython, to reduce memory usage and ensure the system could barely meet the teaching requirements. They also preferred older Python versions like 3.6 or 3.7.
An important point that can be illustrated with examples is that older environments are quite common, and the software running on these outdated and restricted versions tends to be equally outdated.
As for CPython, version 3.11 is already very new, and users who can use this version rarely lack a 64-bit environment. In most cases, it’s just a coincidence that they are using 32-bit CPython. I believe these situations should not hinder the rapid iteration process of CPython.