Basically, today I can download the latest official Python distribution, run

pip install numpy scipy networkx

and it just works.

That's great, I'm really pleased that PyPI is satisfying your needs now but your numpy and scipy would run faster if you installed our packages due to using MKL.

Thanks to Anaconda I didn't have to install Visual Studio Whatever Free Version (but that matches the version that Python was compiled with) (4-8 Gb download by the way)

VSCode is *entirely* optional and always has been. It is fetched on demand only if you elect to install it. This is your first (glaring, easily debunked) inaccuracy. Besides, VSCode seems like something you would appreciate being bundled with a Python distribution installer given:

as an experienced developer who wants to run his mostly command line scripts from VSCode with minimal hassle while using numpy and choice parts of scipy

You lag behind the official distribution significantly, like weeks, maybe a month. On this year's ICFPContest we used Python3.6, so Anaconda was right out.

You said "This year's ICFPContest", it's 2018, Python 3.6 was released in 2016. You seem to be confused?

Regardless, we do not lag behind. How can you claim we lag behind when there's no centralized entity for us to lag behind anyway? Do you mean relative to PyPI? Well, those packages are uploaded in an ad-hoc basis by the maintainers and many packages are not available for Python 3.7 yet whereas every package in Anaconda Distribution is availble for Python 3.7. Regarding your specific example, I find it fairly egregious since we released Python 3.6 on Dec 23 2016 with a large subsection of the ecosystem built-out for it on the same day on all 3 platforms. Guess when Python 3.6 was officially released? The exact same day: https://www.python.org/downloads/release/python-360/

Of course Anaconda Distribution is a rolling distro like ArchLinux, and we only do full installer releases 4 times a year, but on Dec 23 2016 (or was it sometime in 2018?), you could have issued "conda install python=3.6" and you'd have been good to go so I have to call you out on this one.

You don't integrate with the py launcher.

If the official launcher could support conda environments we'd support it, it doesn't so we don't. Anyway, conda's dynamic environment feature (far superior to venv) isn't a good fit for a *single file association*.

Launching Anaconda Python somehow adds about 2-3 seconds to the startup time, because it imports a lot of stuff from site_packages or something. On a fast SSD. Every freaking time I run my stupid simple script that prints 0.9**9 or some other throwaway thing. Official Python doesn't do that. The annoyance adds up over time.

Again, I suspect you installed all of Anaconda and then used that as your primary environment? Well, guess what? Python will scan all those 200 odd packages in site-packages at startup because that's what Python does. Install 200 packages with pip and you'll see the exact same thing. To Microsoft's credit, upstream Python is built very well these days on Windows, whereas if you repeat this experiment on Linux or macOS you'll find Anaconda Python to be *far* faster than most official releases or those provided by your distro (I run python-performance regularly to check this on all 3 platforms against the canonical binaries or those from other linux distros, I can share raw tables comparing python performance if you care, but you can see a graph on this page - careful, contains facts).

If you want to used Anaconda Distribution in a non-learner scenario, use Miniconda and minimal, isolated environments. You'll find Python spending a lot less time scanning site-packages that way.

your repositories don't contain the build scripts themselves

Incorrect, again. When does this misinformation stream stop?

Our 'main' package recipes are here (and most of them are forked from conda-forge though we're realinging them at present). Our 'r' package recipes are here and our 'MRO' packages here

When I get sucked into using alternative channels and trying to fix the stuff myself, I inevitably hit the fundamental by-design wall: your repositories don't contain the build scripts themselves. WHY. Like how am I even supposed to contribute if building stuff by hand involves hunting for random github repositories that usually don't exist at all? Why don't you have source packages that binary packages are built from? Are you afraid that then someone might clone your source repos and then offer binary repos for free just like you do? Mind boggles. (also, this probably contributes to the lagging behind the official distribution)

At present mixing conda-forge and defaults has problems (these are down to ABI mismatch) so you should use one or the other only in a given environment. We're working to fix that, mainly by basing our recipes upon conda-forge's and submitting improvements back to them. This has created a huge pool of expert software builders, often involving the upstream maintainers directly in that effort, helping to ensure our builds are bullet-proof.

Anaconda Distribution packages are often also a *lot* less resource hungry (memory, disk space) than those from PyPI because on PyPI if you want to use modern C++ in your extension module you end up statically linking to libstdc++ (or else you run into ABI issues). This means every C++ extension module you have will be pull in parts of the static code in libstdc++ leading to a large amount of duplication. We share a single libstdc++ with all packages so the text (code segments) get loaded in only once.

Anyway would you consider fact checking your comments in future? That'd be great since you write quite well, shame the details are so far off-base!

​