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 to make check free-threaded/debug builds easier #127405 (comment)
• Set sys.abiflags on Windows to make check free-threaded/debug builds easier #127405 (comment)

---

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

• Issue: Set sys.abiflags on Windows to make check free-threaded/debug builds easier #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]

but certainly a lot that are likely to find the warning noisy.

In regular release builds, DeprecationWarning will be ignored by the default warning filter.

---

Ref: https://docs.python.org/3/library/exceptions.html#DeprecationWarning

Ignored by the default warning filters, except in the __main__ module (PEP 565). Enabling the Python Development Mode shows this warning.

---

Ref: https://docs.python.org/3/library/warnings.html#default-warning-filter

Default Warning Filter

By default, Python installs several warning filters, which can be overridden by the -W command-line option, the PYTHONWARNINGS environment variable and calls to filterwarnings().

In regular release builds, the default warning filter has the following entries (in order of precedence):

default::DeprecationWarning:__main__
ignore::DeprecationWarning
ignore::PendingDeprecationWarning
ignore::ImportWarning
ignore::ResourceWarning

In a debug build, the list of default warning filters is empty.

Changed in version 3.2: DeprecationWarning is now ignored by default in addition to PendingDeprecationWarning.

Changed in version 3.7: DeprecationWarning is once again shown by default when triggered directly by code in __main__.

[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.