I think making this _d is more useful. Provided we keep the t before it, it means a free-threaded debug build has ABIFLAGS of t_d, which means python{version}{ABIFLAGS}.exe will correctly generate python3.13t_d.exe. Without the underscore, you can't use ABIFLAGS anywhere, so it's pretty pointless.

Without the underscore, you can't use ABIFLAGS anywhere, so it's pretty pointless.

Can't we use something like this?

def add_underscore_d(x):
    if os.name == 'nt':
        return x.replace('d', '_d')
    return x

executable = f'python{version}{add_underscore_d(ABIFLAGS)}.exe'

Explicit is better than implicit.

It isn't "we" - it's "every single user ever for the rest of time". Our job as core maintainers is to do more work and make less obvious decisions so that every single user doesn't have to.

Don't bother quoting the zen at me either. "Special cases aren't special enough" applies just as well here, as does "one obvious way" (which is to use sysconfig variables to construct system configuration values).

If you want to run with the "explicit > implicit" argument, here's a more explicit version:

executable = f"python{version}{'t' if 'freethreaded' in sys.abi_features else ''}{'_d' if 'debug' in sys.abi_features else ''}.exe"

Inserting an underscore is neither explicit, nor obvious, and is definitely a special case that isn't special enough to not just use a sysconfig variable directly.

I added the underscore prefix in the Python code so that developers can introspect the source more easily.

A constraint of the _ prefix is the d flag should always be the last flag (test added). And users cannot use ABIFLAGS.split() to get the components because _ is not a valid flag.

users cannot use ABIFLAGS.split() to get the components because _ is not a valid flag.

Users can't split up the value anyway, that's not what it's for. You can parse it specifically, which basically amounts to an in test for a single character (and will be replaced by sys.abi_features), or insert it into certain places without modification.

I still don't understand why this definition needs to be in the native module, instead of generating it in the Python code.

Ideally, as you say, all these variables should be defined in pyconfig.h. Let's call that tier 1.¹

On Windows, we don't parse pyconfig.h to fill out sysconfig, so instead we set the variables we want in _sysconfig. So that's tier 2, and is closer to the ideal (tier 1). If we had an actual build-time ABIFLAGS then we'd have to put it in _sysconfig. And I'm not opposed to constructing an AbiFlags property in python.props and passing that through to _sysconfig at build-time, but it'd only change the current implementation by a couple of lines.

If not set in _sysconfig, then we are constructing an arbitrary variable purely for cross-platform compatibility reasons, and so we can do that in sysconfig (tier 3), but so can anyone who needs it. By definition, if we can construct it in Python code, then so can they, and if they do it then they can backport further than we can (basically the same as the argument for removing distutils). It's more flexible for libraries that need it to figure it out themselves from first principles, and in reality, I don't think most bother, because it's just not that important a variable.

So basically, tier 2 is closer to ideal than tier 3 would be, and importantly it makes it clearer that this is exposing an internally defined value, rather than trying to adhere to some kind of definition of what ABIFLAGS is meant to be (which doesn't exist). A combination of expressing our intent more clearly along with being in a better position to do it properly one day.