Given the alternative of usingsysconfig and PEP 780's proposedsys.abi_features, I'm not sure this is worth it. Adding aDeprecationWarning 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 thatsys.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.

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

Thesys.abi_features alternative does not replace the incoming change ofsys.abiflags and vice versa. Both can benefit the community independently.

The recent update of theaction/setup-python adds3.13t support (release note). I changed the code to determinePYTHON_TAG which is used in the artifact name (e.g.,coverage-${{ env.PYTHON_TAG }}-${{ runner.os }}.xml) inhttps://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 validsys.abiflags on all platforms.

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

I think we can still apply this to 3.14 during beta, but I'm still not convinced we need to. Thesysconfig 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 (mainlysys._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 usingsys.abiflags either).

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 assysconfig.get_config_var("ABIFLAGS") after#131799.

However, as commented in#131799 (comment), variables insysconfig.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 makingsys.abiflags generally available:

1. Forward- and backward-compatibility guarantees.
2. Keep consistency betweensys.abiflags andsysconfig.get_config_var("ABIFLAGS") on Windows.
3. Member with static name (sys.abiflags) is easier to inspect than getting value fromdict[str, Any] via strings (sysconfig.get_config_var("ABIFLAGS")).
4. Make static tools happy, such asmypy.mypy recognizessys.version_info andsys.platform while not acceptingplatform.system().

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

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, includingall 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 issysconfig. We don't need consistency, we need people to ignore thesys attribute (which is only there to make the value available insysconfig - 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 fromsysconfig. 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.

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