There's two other registry locations we need to apply the same process to, to find user-land installations and 32-bit installs on 64-bit Windows.

Thanks for your help with all this -- greatly appreciated. Do you know what the other paths would be? I can get back to looking at this soon.

Per PEP-0514, the three registry paths that need to be checked are:

HKEY_CURRENT_USER\Software\Python\<Company>\<Tag>
HKEY_LOCAL_MACHINE\Software\Python\<Company>\<Tag>
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\<Company>\<Tag>

You can check them all the same way, there's some notes there about what to do if you see the same Company-Tag combination in different registry paths, and specific notes about how to disambiguate 32-bit and 64-bit Python older than 3.5, which did not include architecture in its Tag, and so has the same Company-Tag for 32-bit and 64-bit installs.

Just took a stab at the refactor, not really sure if it's 100% correct though.

It'd be nice to support non-PythonCore environments at some point, e.g., conda.

Probably need to continue if install_path comes back as None (or rather, as an empty string, I suspect, since this lookup cannot fail if OpenKey on the line above passed, so we'll never get our default value back), as it's not a valid Python install in this case. (And for example, the PythonCore defaults below will be nonsensically in the root of C:)

I suppose the except FileNotFoundError on line 383 was supposed to take care of that, but _get_registry_value currently handles that exception internally, so I don't see how that exception handler (nor the one on line 386) can actually get hit except for the initial winreg.OpenKey call.

Maybe self._get_registry_value needs to be able to know the difference between a usable None default, and "This key is required, bubble the exception up".

That said, if the expectation is that this code can spit out invalid WindowsLauncherEntry values that are handled later, e.g., by higher-level code checking that install_path is a valid and rational path and actually matches the sys.prefix in the resulting Python environment, then you can ignore this comment. ^_^

This doesn't capture install_path. I'm assuming the usage in PEP-514 (i.e. sys.prefix for that installation) is what's expected for WindowsLauncherEntry.install_path in this code, but I don't fully understand the places it's used anyway. Is it just used to for more-efficient lookups in an internal dictionary?

These defaults are only applicable for company == "PythonCore". It might make sense to have these all default to None and have a single block which populates all missing values for PythonCore only in one hit. (Or perhaps, just add these to the block that already exists inside the InstallPath block.)

I'd also suggest annotating the Version and SysVersion defaults to be clear that they are correct per-spec. Casual inspection of the code would note that Python 3.10 and Python 3.11 will both produce default Version and SysVersion of "3.1", which is clearly wrong. (But knowing that the defaults are only needed for Python installs older than Python 3.5 means that this case should never happen, but you can't tell that from the code.)

An empty executable_path (after allowing for PythonCore defaults) means the environment is not executable. Should we skip outputting a WindowsLauncherEntry in that case? Or is that still useful to expose?

Back-compat logic should be something like:

import platform
if key_path == r"Software\Wow6432Node\Python" or not platform.machine().endswith('64'):
  # 32-bit registry tree or 32-bit OS: https://stackoverflow.com/a/12578715/166389
  sys_architecture = "32bit"
elif hive == winreg.HKEY_LOCAL_MACHINE:
  # 64-bit OS and system-wide install that's not in the 32-bit registry tree
  sys_architecture = "64bit"
else:
  # User install on a 64-bit machine: Unknown architecture, we'd need to run the executable to find out.
  sys_architecture = None

We could probably capture the default value right at the top of the outer loop, since it depends only on hive and key_path, but not the contents of company_key, even though using the value depends on the company value.