gh-127405: Emit a deprecation warning about a future change of sys.abiflags availability on Windows

[XuehaiPan]

Emit a deprecation warning when accessing the sys.abiflags member if it is absent:

>>> import sys
>>> getattr(sys, 'abiflags', None)  # on Windows
<python-input-1>:1: DeprecationWarning: sys.abiflags will be set to a meaningful value on all platforms in Python 3.16 instead of absent
>>> hasattr(sys, 'abiflags')  # on Windows
<python-input-2>:1: DeprecationWarning: sys.abiflags will be set to a meaningful value on all platforms in Python 3.16 instead of absent
False

See also:

• Set sys.abiflags on Windows #127405 (comment)
• Set sys.abiflags on Windows #127405 (comment)

---

📚 Documentation preview 📚: https://cpython-previews--131717.org.readthedocs.build/

• Issue: Set sys.abiflags on Windows #127405

[colesbury]

Given the alternative of using sysconfig and PEP 780's proposed sys.abi_features, I'm not sure this is worth it. Adding a DeprecationWarning still imposes a cost on users because now they have to change their code to avoid or suppress the warning. The benefit of such a change would still be years in the future, at which point I'd hope that sys.abi_features would be a better alternative.

I don't feel particularly strongly about this, so if @zooba thinks this is a good approach, then it's fine with me.

[XuehaiPan]

The benefit of such a change would still be years in the future, at which point I'd hope that sys.abi_features would be a better alternative.

The sys.abi_features alternative does not replace the incoming change of sys.abiflags and vice versa. Both can benefit the community independently.

The recent update of the action/setup-python adds 3.13t support (release note). I changed the code to determine PYTHON_TAG which is used in the artifact name (e.g., coverage-${{ env.PYTHON_TAG }}-${{ runner.os }}.xml) in https://github.com/metaopt/optree/pull/198/files.

export PYTHON_TAG="$(
  echo 'import sys, sysconfig; print(
    "{0.name[0]}p{1.major}{1.minor}{2}".format(
      sys.implementation,
      sys.version_info,
      getattr(sys, "abiflags", "t" if sysconfig.get_config_var("Py_GIL_DISABLED") else ""),
    ).lower(),
  )' | ${{ env.PYTHON }} -
)"

This would benefit from a valid sys.abiflags on all platforms.

The incoming sys.abi_features would be useful. But in scripting and CIs, a good sys.abiflags can make the inline code shorter and easier to maintain.

[XuehaiPan]

Are there any details about the existence of sys.abiflags for cross-compiling for Windows on Ubuntu? I found it might be non-trivial to replace the following with one another:

hasattr(sys, 'abiflags')
os.name == 'nt'  # os.name != 'posix'
not sys.platform.startswith('win')

[picnixz]

This requires a full-fledged What's New entry + possibly under the incompatible changes / porting to Python 3.14 code or something like that.

[XuehaiPan]

The first beta version of Python 3.14 is out. Any comment on this?

[zooba]

I think we can still apply this to 3.14 during beta, but I'm still not convinced we need to. The sysconfig variable exists and should be sufficient for those who need build flags, and there are other mechanisms for those who want to know at runtime (mainly sys._is_gil_enabled).

So I still worry that we're effectively adding a new and unspecified API here when we ought to be trying to remove the same API from everywhere else (as in, I don't think POSIX users should be using sys.abiflags either).

[XuehaiPan]

I think we can still apply this to 3.14 during beta, but I'm still not convinced we need to. The sysconfig variable exists and should be sufficient for those who need build flags
So I still worry that we're effectively adding a new and unspecified API here when we ought to be trying to remove the same API from everywhere else (as in, I don't think POSIX users should be using sys.abiflags either).

Yes, this functionality can be covered by other APIs, such as sysconfig.get_config_var("ABIFLAGS") after #131799.

However, as commented in #131799 (comment), variables in sysconfig.get_config_vars() are not documented and do not hold forward- and backward-compatibility guarantees. They are also implementation dependent.

The rationale for keeping and making sys.abiflags generally available:

1. Forward- and backward-compatibility guarantees.
2. Keep consistency between sys.abiflags and sysconfig.get_config_var("ABIFLAGS") on Windows.
3. Member with static name (sys.abiflags) is easier to inspect than getting value from dict[str, Any] via strings (sysconfig.get_config_var("ABIFLAGS")).
4. Make static tools happy, such as mypy. mypy recognizes sys.version_info and sys.platform while not accepting platform.system().

PS: the incoming sys.abi_features in PEP-780 is targeted to Python 3.14. And it partially resolves (3) and (4). But it has not been implemented yet.

[zooba]

The rationale for keeping and making sys.abiflags generally available:

• Forward- and backward-compatibility guarantees.

We can't make guarantees about this API as it stands. It needs a PEP and documentation to properly define it, including all possible values. Without that, it'll always have no compatibility guarantees.

• Keep consistency between sys.abiflags and sysconfig.get_config_var("ABIFLAGS") on Windows.

The correct source of the information is sysconfig. We don't need consistency, we need people to ignore the sys attribute (which is only there to make the value available in sysconfig - it was added before _sysconfig existed).

• Member with static name (sys.abiflags) is easier to inspect than getting value from dict[str, Any] via strings (sysconfig.get_config_var("ABIFLAGS")).

Perhaps true, but then you have hundreds to move from sysconfig. Justify why this one is too special.

• Make static tools happy, such as mypy. mypy recognizes sys.version_info and sys.platform while not accepting platform.system().

It's up to mypy to figure that stuff out. It shouldn't have anything reliant on abiflags anyway, as abiflags don't impact the Python language at all.

I don't think any of these reasons are good justifications.

[XuehaiPan]

Since #131799 is merged, I would like to close this PR and issue #127405 once sys.abi_features (PEP-780) gets implemented.