[woodruffw]

> That's not a reason to not use it.

It is, in fact, an excellent reason not to use it. Homebrew runs on tens of millions of machines; we are absolutely not going to rely on things that we're told not to rely on unless absolutely necessary. Python is readily buildable and we already need to build multiple versions for reasons aforementioned, so this condition does not apply.

Also note, it's stronger than what I originally said: 10.15 doesn't ship with Python by default at all anymore. I only have it installed (at 3.9.6) because I also have XCode installed. Homebrew supports being used without XCode or the CLT, so that alone would be a hard blocker for system Python for us.

> Are you guessing or do you know? Try it out. Prove me wrong.

My `uv python list` shows that I have 3 uv-managed versions of Python installed, along with 5 pyenv versions and 2 Homebrew versions. I have more than most people because I test large matrices of Python versions at once, but I imagine a normal Python developer isn't too far off.

You can test this for yourself with the same command. If you're developing more than one Python library or application at a time, I strongly suspect `uv` or `pyenv` is using more space for Python versions than Homebrew is.

[godelski]

  > an excellent reason not to use it

You're really missing my argument here.

  >> there's something cheaper than storage: infrequently scanning the system!

The solution already exists

  If required python version does not exist, download.

This is already being done. The missing part is the scanning of the system. I need to make this abundantly clear: You do not need to rely on Apple for this to be a solution. Furthermore, even if Apple completely removes python, making this change would still improve brew and reduce bloat. This is why I didn't care about that comment. Because it is inconsequential to what I'm suggesting. If they remove python you're in the exact same position as not having the right version of python. It is equivalent. I'm not sure why you're harping on this.

  > My `uv python list` shows

You're again missing the point. It isn't about having different versions, hell I got 3.13, 3.12, 3.11, 3.10, 3.9, and 3.8 on my system. The problem is having redundant copies of the minor (or even patch) versions. When I installed `uv` I uninstalled brew, purged everything, and reinstalled. This is because when I'm creating a new venv it isn't actually `uv` that is installing a new python version, it is linking one that was installed by brew. When I was using Anaconda, conda didn't search for existing versions (and packages), it just installed its own. You might be thinking this isn't a problem with brew and a problem with conda, but that's passing the buck. Brew is making the same error that conda was and thinking brew is better and that the solution should be fixed by others is just idiotic. Its blaming those downstream for a problem that's being created. If a "crime" is a "crime" then it doesn't matter who does it.

We're getting off topic now, since this is besides the point. But hey, here's a few things that can help look at the system and what's happening.

On my system, brew installed 3.13, 3.12, and 3.11 (you can guess when I purged). For good measure, try this instead

  brew list | xargs -P8 -n1 sh -c 'brew cat "${0}" | grep "depends_on \"python@3." | sed -e "s/.*\(python@3\.[0-9]*\).*/\1/g"' 2> /dev/null | sort -u

This will go through all your brew packages and find the python depends. My output shows 3.11 and 3.12. Interestingly, no python 3.13, though brew installed this. Interesting considering brew and brew-core don't have python code (according to github). Maybe something installed it and then I removed it. I'm unsure. But let's edit our command and check only those python@3.11 instances.

  brew list | xargs -P8 -n1 sh -c 'brew cat "${0}" | grep "depends_on \"python@3.11" &> /dev/null && echo "${0}"' 2> /dev/null

I checked the formulas on github, none of those even have python 3.11 anymore. These are cryptography, libxml2, numpy, py3parser, py3cairo, python-cryptography, pygobjects3, and python-packaging. With the exception of python-cryptography and python-packaging (no GitHub formula), the brew formula on GitHub depends on both 3.12 and 3.13 for every one of these. There is no dep for 3.11! Did a `brew update` and `brew upgrade` and they're still 3.11. But hey, now the first brew list command reports 3.11, 3.12, and 3.13. Doing `brew info python-cryptography` there's a green checkmark on `python@3.12` and `python@3.13` (`python@3.11` is not shown), while `python-setuptools` has a red x despite the fact that I have setuptools installed in both 3.13 and 3.12 in different uv environments (it also isn't finding rust). So it certainly isn't finding packages and trying to reduce redundancy which is the big problem `uv` tries to solve in the first place.